What we wish we'd known before building the Prismatic Android app
github.com
github.com
The primary blunder companies make on doing an Android app is they pretend they're making an iOS app. This is very widespread.
The company has a database. They have a website. They have an iOS app which connects to a web API connected to that database. They have a designer who makes his 2 (or 3?) designs for each iOS form factor.
Then they decide to make an Android app. The web API is usually OK. But it becomes decided that the company will ignore that Android's come in tablets, very small phones with low resolution, phones with very high resolution, "phablets" etc. It becomes decided that the goal will be to make a pixel perfect design (just like for the iPhone!) for the Android phone the designer has, and perhaps the other one the boss has, and then to just pretend that the other 99% of the Android market does not exist.
There is more Android work then experienced Android programmers, so some inexperienced kid right out of college is the programmer on the project, who is easily intimidated by the designer. They proceed this way until weeks and months go by and the CEO realizes the app looks like junk on tablets and most phones, and then blames the programmer for this situation.
Anyone thinking of stepping into a role as an Android programmer should get everyone on the same page about the UI goals before he agrees to work on the project. Especially between you and the designer and whoever your common management is, perhaps all the way to the top. Because the easy way is for the designer to do what he did for iPhone - 2 designs for the 2 phones he has access to, which are pixel perfect (which is completely pointless if it looks like crap on 99% of phones).
This situation arises again and again and again.
If there's any secondary thing, I guess it would be how far back you want to support Android in terms of versions. You really don't want to support something before v3.0 if you can avoid it.
https://developer.android.com/guide/components/fundamentals....
We were admittedly in the position you describe: a company of majoritively iPhone users who shipped the web & iOS apps, cleaned up the API and were starting on Android.
I don't think there's a perfect solution but we found digging into some of the guides & sample apps listed here to be particularly useful: https://github.com/nstevens/androidguide/wiki/General-Androi...
We also ordered a range of devices and hooked them up to our Play Store alpha channel so every build had to go through the 3" phone and 10" tablet test.
Finally, it helped to have a couple hard core Android users on the team who could explain why simple features like the 'back' button are truly game changers. There's a good post on some of these differences here: http://paulstamatiou.com/android-is-better/
P.S. I was being facetious about missing Make. Point stands.
"a port from Ruby to JS using Opal transcompiler, a Rake build script, a Grunt build, using the Rake build underneath."
I suddenly felt as if I didn't understand computers anymore.
> This project uses Opal to transcompile Asciidoctor—a modern implementation of AsciiDoc—from Ruby to JavaScript to produce asciidoctor.js, bringing AsciiDoc to the browser!
The whole point is to not rewrite it in JavaScript but to piggyback on the original Ruby implementation and just compile it to JavaScript so it can run in a browser.
I feel confident in saying that because the thought of permanently standardising on any existing build or configuration management tool fills me with horror. In the JVM world, ant is inadequate, Maven is diabolical, Gradle is a huge step forward but has many warts and one or two fundamental mistakes, and sbt is just vile. Gradle is good enough to be getting on with, but i'm looking forward to the next step.
Provided, that is, that the next step is taken after learning from previous steps. Sometimes that happens - Ansible and Salt are clearly attemps to improve on the overcomplexity of Puppet and Chef. Sometimes it doesn't - i'm not sure that Gulp or Leiningen do anything to help.
Check out Buck. It's fast, the codebase and general complexity is a tiny fraction compared to Maven or Gradle, and it's more sound in at least one fundamental way. (It uses file hashes instead of modtimes to figure out if a task has to be rerun.)
I agree with the rest of your post. Most build systems suck. Here's an off-hand idea:
All build systems I know work share the same core concept, a directed acyclic graph of tasks. Each task has inputs (which might be the output of another task) and if the inputs are changed then the task is rerun. That same idea also covers a lot of systems for data processing.
Why can't we have a simple, minimal tool for doing only that? Then, we could plug in different task definitions for different uses (eg building a Go project, a Java project, or running a data pipeline).
This seems preferable to a bunch of different application-specific build systems that each roll their own DAG, and their own DSL for defining tasks.
Yes. And, that thing is forgetting to teach history to people. There was a story a few days ago about a father pushing his son to play video games in chronological order [1]. Perhaps we need to do something similar in software development.
[1] https://medium.com/message/playing-with-my-son-e5226ff0a7c3
I really like your idea. Imagine a book, class or structured tutorial that sliced up the history of web development (or UI design, Windows app development, parallel programming, game development, network communication, systems administration, mobile development, or any other kind technical topic) into a handful of important "eras" and spent a couple hours or days on each one doing a technical deep dive. Boot up a VM, install the dev tools of the day, have your hand held through some characteristic tasks so you could see first hand how people were thinking during that era, what kinds of things were easy to do, and what was hard. As you move to the next era, you get to see the results of the lessons that were learned (or not learned!) in the previous one.
The more I think about it, the more I like this idea.
Sidenote: If anyone knows someone at Penguin, can you help me get permission to put Peter Norton's book on GitHub and update it?
[1] Tetris2nand does not exist. The idea would be to build the "ideal programming language" and then work your way down to the hardware, exploring things like GCs, parallelism, and more along the way.
Though personally I use HockeyApp as you can upload iOS/Android apps and they become immediately available to testers — no waiting for several hours for your apps to appear, as occurs with Google Play. HockeyApp doesn't tie you to a particular form of user management either. Hopefully Microsoft doesn't change too much there.
I'm sure something like this exists right?
Dagger 1.x (which we currently use) certainly helped slim down code size but it's mix of compile time and run time injection made using tools like Proguard a bit messy. We haven't made the jump yet but it seems like Dagger 2.x solves for this: https://github.com/google/dagger
Butterknife is just plain useful to avoid a ton of view boilerplate code.
Our app is admittedly not too complicated but so far we haven't seen any performance issues.
Butterknife and Dagger both use compile-time generation, so they're basically free and make your app well structured. I really wouldn't avoid 3rd party libs in your position, using good ones will make your apps less buggy and will let you easly create way better UX for your users.
For example, EventBus (or Otto, both do the same thing) is pretty essential for coupling things together and keeping them working over orientation and other configuration changes. I've seen so many apps locked into portrait position just because devs couldn't figure out how to decouple model from views and keep the app running over orientation change.
In most cased the inner fragment could be made into a custom View, and those work a lot better. Most new Android developer do not make enough custom views. They are the fundamental unit of UI re-use. It's relatively simple to extends FrameLayout or RelativeLayout, encapsulate a view normal views, layer your logic on top, and you have a nice usable component.
However, in our v1 the only fragments that share an activity are our main feed & story view. All other's have their own activity. It made data flow a lot easier, our manifest file a lot cleaner when filtering for intents, etc.
Interested to hear any tips if you have them!