Square Open Source

I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly.

Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this.

Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs.

Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier.

I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually.

[0].…

I've found that the much more annoying and difficult to deal with fragmentation bugs are carrier specific. You will find things like Samsung has changed how you launch the default browser from your app or HTC doesn't follow the spec for getting an image from the camera. These are the kind of bugs that drive me crazy.

My current project runs a test suite (as well as some light adhoc testing) on 6-7 devices (across screen densities and carriers) and that seems to catch most of the issues without spending $20k on a device lab. (We use the excellent Spoon library by Square: http://square.github.io/spoon/)

Screen sizes are not an issue for anyone that's shipped a non-toy app. API levels are not so bad - though you will find yourself using the Support Libraries even in cases when they shouldn't be needed.

BTW: Android provides a weekly report of OS/screen sizes etc that access the Play Store: http://developer.android.com/about/dashboards/index.html Use this (not a random blog post) to make informed decisions for your clients on your minSdkVersion.

Now if you want to talk about a real headache for Android developers, let's talk about Fragments - not fragmentation :)

> Leave data processing and business logic to the back-end, on the server

In general, this is not good. Of course there are specific applications where it's useful but in the general space of applications it would be very limiting.

For example, go to http://square.github.io/crossfilter/ and do the filtering on the 5MB data such that you wait for the histograms to be updated from the server. Instead of the tens of milliseconds, it might be seconds or tens of seconds if the server is loaded, i.e. orders of magnitude slower, not to mention unpredictable.

You can think of the network as a data flow constraint. It constrains latency, throughput, privacy and security; the constraints can be unpredictable (network outage; DoS, MiM attack etc.). There can be many good reasons for wanting part of your domain specific logic to fall on the client side.

In particular, dynamic media e.g. interactive data visualization, games and most interactive things that use data or modeling are best partly in the browser.

We're past the point where the rule of thumb was to do business logic on the server and the client only did the presenting of the view and acted as a controller.

Interesting project! It's nice to see some better examples for this sort of thing. At work I've helped build something similar using javascript. We needed something that works in-browser, and have since made sure it also works within web-workers as well as node.

It's not as nice as directly running calculations from a magically scalable and performant spreadsheet black box, but importing data and formulae from various spreadsheets has gotten quite easy.

Closed source, but imagine using the core and expressions support from mathjs [0] and crossfilter [1] together to display both raw and calculated data in various contexts, and you wouldn't be too far off the mark.

[0] http://mathjs.org/

[1] http://square.github.io/crossfilter/

[edit for grammar]

There sure are a lot of these systems these days. While I'm always happy to see innovation in this area, I'm personally beginning to get confused as to why I might prefer to use (and probably then contribute to) one of these projects over another. After all, there's this, and Lyft's Confidant [1], and Square's Keywhiz [2], and plenty more that don't come to mind right now. They all have nice documentation about what they do, but none of them sufficiently explain to me what architectural differences they have, their pros and cons. I think it would be great to see that added to these products' pages at best, or at least some guy write a blog post about it.

[1] https://lyft.github.io/confidant/
[2] https://square.github.io/keywhiz/

Some of the fault for this lies with client libraries. Many, including popular ones[1], either don't provide a way to get the body of error responses at all, or make it particularly cumbersome to do so. For example, success bodies might be parsed automatically by registering the right parser for the content type, but to parse an error response you need to manually instantiate a parser and deserialise the body. Until error responses are first-class objects in client http libraries, devs will continue being lazy.

[1] Not to pick on retrofit -- it is generally awesome -- but http://square.github.io/retrofit/2.x/retrofit/retrofit2/Response.html