News for hackers. Stuff that matters.
Re:Solving Android’s 65K Limit: The Unbearable Lightness of ... by Zigurd on Friday June 19, 2015 @03:58PM (#9747261)
The first, second, and third thing I would try is dividing up the app. I suppose there are things that might be better off as a monolith, like maybe a really powerful CAD app with an in-memory data model.

But in most cases, where the data model is in a SQLite database, you can put that in a ContentProvider and have multiple apps access it.

"But that's not how we designed it." OK. OK. Just saying. It's a mobile device. It has constraints. It also has benefits for implementers who don't try to just steamroll the limitations.

Re:Solving Android’s 65K Limit: The Unbearable Lightness of ... by on_and_off on Monday June 22, 2015 @04:57AM (#9757047)
MultiDex brings its own problems with it. First it makes compilation times even worse, but it can also lead to unpredictable crashes during class load for Android < 5.0. Before using it, you really need to try to get under the 65k limit instead.
Re:Solving Android’s 65K Limit: The Unbearable Lightness of ... by offerico on Thursday June 18, 2015 @11:56AM (#9739399)
Good post. I am using Proguard and still have more than 50K methods. Good to know there are other solutions