Full stack developers
We were all been there, you got a great idea for an app, you gather some feedback and even managed to build a team and you going full power to conquer the app store. So a second before starting working on your genius egg timer app, it is worth taking a moment and think about how you’re going to do it.
Following the hilarious post by Chet Haase about 10 good rules for bad API, I decided to put together my list about how to build a bad app. but a few notes first:
Enough said, lets start with the list:
You know what your app worth, don’t let minor things like user privacy get down your way. The user is begging for this crucial analytics sending on boot, so go and ask that BOOT_COMPLETED permission! If you need to share this wonderful url to your user’s friends- pull the fucking contact list from his phone, and while you doing so why not sending it to your server and spam them all? Remember- data is power, and other’s data is money!
Bonus point: when implement Android M permissions, don’t let the user do anything until he or she accept your permission, even if he accepted some, don’t let him win!
Hey dude, we’re loading, we’ll really appreciate if you let us do our thing and don’t interrupt us with some stupid ui events, just sit quietly and wait us to finish processing all this 3.4M config xml file ok?!
Yes we’re still waiting for this config file, it’s your fault for living in this shitty connectivity area, don’t blame us for sucking all you data plan and battery alright?!
You snooze you lose, you rotated the screen? Boom- your form was lost. This is the best way to teach your users never leave your app, even if them just got a phone call.
Alarm manager is get tool by Android to execute code in some time in the future. The thing is timing is everything and the Alarm Manager has some options for firing the code smartly and rescheduling it depending on phone state, battery, network or other tasks that can piggy bag. But you probably don’t need those fancy features, there’s nothing like putting your “Please update our app” notification waking you app 6AM.
Bonus points: combine setExact + RTC_WAKEUP to the same time for all your users for your network request to your servers for taking your load balancer to the edge.
Because why not? Save your application context as a static member in your Application class on onStart and use it everywhere- so easy, so simple, so not modular, make it horribly when you want to debug theming errors and make your tests a nightmare. Win Win!
That’s make it much easier when something goes wrong on the users side, so they’ll just forward you the message. That’s also make your app a developer-friendly so people like me can easily understand that they missing a certificate to the https connection and that’s why the app keep crashing when sharing a photo.
Android has a very strict limit of 65k methods limit, after importing google play and support libraries that’s barely leaves you with room for 3rd libraries. Anyway, how hard is it to handle Json parsing? you don’t really need this Gson library. It’s also a great opportunity for your junior dev to practice his poor implementation of string pattern matching from his job interview.
Great, you just implemented the sorting by yourself, probably with bucket sort, because you know the data going to be evenly distributed, probably, you think so… You also saw the talk by Romain Guy and Chet Haase (him again?) and switched all you enums with constants ints and use objects pull everywhere even if this just one time function because who know what can happen.
You know what they say- Premature optimization is the root of all evil, but a greater women also said: “There is no good and evil, there is only power and those too weak to seek it.” and I hope you see the power on N when implementing those graph algorithms.
Move it all- Android specific functionality, networking calls, permissions checks, input checking, not-object-oriented-never-going-to-be-able-to-test code it all goes here.
Bonus points: have a Util and Utils classes, because one is not enough and confusing is a plus!
That’s all until the next time when we’re going to talk a bit about UI and UX, Got some more suggestions for ways to make your code worse? Would love to hear your thoughts in the comments!
Originally published at shem8.github.com on March 31, 2016.
Create your free account to unlock your custom reading experience.