https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...

They did finally provide a method to use a custom root CA for SSL a year later, https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/....

They seemingly failed to comprehend why anyone would not want to use TI's chain of trust, that is not manufacturer customizable, on proprietary IoT devices. This was explicitly an issue for code signing as well, as it required obtaining a third-party code signing certificate from any number of CA's instead of using our explicit root CA.

[edit] spelling, clarity

Their GBM specific list is here

http://braintrust.org/groups/gbm/

Edit:spelling

One of the biggest issue of running Apps (open source or not) is the inclusion of the Play Store API in the app itself. These apps when not logged into the play store usually crash with NullPointerExceptions. Please... if you are an Android developer... expect your third-party services/APIs to be missing or to crash and handle that case... If you include the Map API or several other Google Services APIs in your app and the Play Store is missing or the user does not have a registered account... calls to those services will most likely result in NullPointerExceptions. Tell me to deal with it, don't crash.

Not the good ones. Normal operation isn't when you're dealing with a mobile device, there could be any number of reasons why your app can't reach a certain service delivered by some API so better to be prepared for that eventuality.

You have to balance the tradeoffs of bloated code and pointless error checking with adding features and improving the program. The more error checking code one writes the more one must maintain and the higher the potential for bugs.

That's an artifact of the chosen environment. Not checking for errors in that environment is a bug.

Besides that what do you do to handle the loss of something your app requires as a basic service? A nice error beats NullPointer but not by much.

And related to null-checking, I took the pervasive approach in one of my apps for fun. It's hilarious - almost 1/3 of my app is checking if something is null. Makes you wish for a switch to a language where nulls don't exist unless explicitly asked for.

Google In-App purchases are safe, so if that's how you monetize, I don't see why the app should be allowed to work anywhere else but in Google's environment.

It's different if the app is open source or you don't need to monetize (sadly, not everyone can afford that luxury), but even there it depends on how important those Play Store API features are to the functionality of the app.

I just don't think that you can follow some rule dogmatically, because for some it might be worth the exposure, for some the extra costs might outweigh the benefits.

This is something that I would decide on a case by case basis.

Sure you can, if the rule is "don't write shitty software that crashes". In which scenario do you think users are more likely to buy: when an app crashes with no indication of what caused it, or if an app pops up a message along the lines of "we couldn't connect to Google Play; is it disabled for some reason?"

Even if they're currently fully unmonetized, many such apps exist on the Play store because they can be updated at any time to include in app purchases, etc.

Developers would be able to see from the crash reports how many NPEs from missing Play Services they're getting and prioritise accordingly.

[1]http://en.m.wikipedia.org/wiki/Fluent_interface

Severely, since what you're doing is mutating the actual state-data of the query object.

  package main
  import "sort"
  type RevIntSlice struct {
      sort.IntSlice
  }
  func (arr RevIntSlice) Less(i, j int) bool {
      return arr.IntSlice.Less(j, i)
  }
  func main() {
    myList := RevIntSlice { sort.IntSlice {1, 2 , 3 } }
    sort.Sort(myList)
    for _, elem := range(myList.IntSlice) {
        println(elem)
    }
  }

But that's more work (and more boilerplate) than simply passing an anonymous comparator to the sort function.

  myArray.sort(new Comparator<MyClass> ({
    @Override
    CompareTo(MyClass lhs, MyClass rhs) {
      return rhs.compare(lhs);
    }
  }));

In any case, there is a more elegant solution in Go, which is simply:

  sort.Sort(sort.Reverse(array))

Nope. Clojure and Haskell. Clojure:

    user=> (sort > (vals {:foo 5, :bar 2, :baz 10}))
    (10 5 2)

    >>> sortBy (flip compare) . map snd $ [("foo", 5), ("bar", 2), ("baz", 10)]
    [10,5,2]