Ricardo's Blog

  • 11:42:43 am on November 8, 2010 | 4
    Tags: ,

    Let me start by clarifying: I like… no, I love the Android API. It’s an elegant, user friendly and very powerful way of developing apps.

    That said, no system is perfect, and there are few niggling issues with Android:

    1. Non-POJO Components: All the main Android components (Activities, Views, etc.) are inherited from concrete classes, and have lots of dependencies on other concrete implementations like the Context class. Not only does this go against the “program to an interface” principal, it also makes TDD and dependency injection (DI) trickier.
    2. No Dependency Management: It’s tricky to re-use Jar files in Android, and it would’ve been nice if the Android platform had been built with something like OSGi in mind, to increase binary re-use and reduce downloads, and generally make developer’s lives easier.
    3. Rigid Tools: While the Android Development Tools (ADT) make Android development easy, they are rigid. The generated source folders can’t be moved from their default locations. For example, if you wanted to move them under the Maven target folder, you can’t. Not only that, but my work with the Maven Integration with Android Development Tools project demonstrates that the ADT isn’t really built for extensibility, with no exported packages.

    That said, there is some work going on to resolve the above. Roboguice is a DI framework written specifically for Android which addresses issue 1 above.

    There is also ongoing work to get the Apache Felix OSGI implementation, working on Android [PDF]. Although, this is hampered by Android’s application security.

    Finally, the Maven Integration with Android Development Tools project will hopefully relieve some of the rigidity of the ADT. I’m also hoping to submit some patches to the Google’s ADT project to export some of the more useful, internal classes to make writing extensions on top of the ADT easier.

    About these ads
     

Comments

  • ColdSnickersBar 6:27 am on November 9, 2010 | # | Reply

    You said: “Context”

    Good lord. This.

    I’m making a video game right now (screenshots) and working a lot with animation and special effects right on the edge, mostly outside the API, but just a little too much into the API. I have been fucking dreaming about Context. I feel like Context is my brother at this point. Like we grew up together. I pass Context around like a hooker on some kind of a community deal. Fucking Context … Jesus. It has to be passed if you need to display anything. It has to be passed to construct any API component that shows anything. If you extend View at all, then Context is going to be your buddy along for the ride.

    But, right now, my largest complaint is the horrible pain in the ass it is to write tests for the Android API. But fucking Context is driving me insane with its shitty special Dalvik-specific implementation that completely ruins any kind of unit or even implementation testing on Android. Holy fucking shit.

    First of all, because Android is Dalvik, not JVM, you have to test on the device if it uses Context. You can’t just run a unit test from the JVM. Nope. So, every tiny little change you make has to build, upload, install, and then run, which really defeats the purpose of testing: quick responsive validation of your code. I mean, if I have to fucking build and then run the whole damn thing to test it, I might as well build and run the whole damn thing and skip testing altogether.

    Now, I could just run my code on the JVM with JUnit if it wasn’t for fucking Context. Fuck! Every time the type “Context” exists in my code, now I must test it through the Dalvik VM, which means: build, upload, install, run. Fucking thing takes like 5 minutes for the tiniest little change! Why even create tests at that point? “Context” is poison to testing. Every time I get the chance to run a test on some rare part of my code that doesn’t have Context in it, I get excited. Like “fuck yeah, I get to run these unit tests from the JVM because they’re not using Context!”

    Sure there are various ways to get around implementing Context in testing. Wrapper classes. Mocks. But then sometimes you just have to use the actual Activity, Context. And then you have to extend the crappy ActivityImplementationTestCase2 class, and that just … you guessed it … builds, uploads, installs, then runs your whole project. Welp!

    In short: fucking Context.

    • PPP 6:19 pm on October 25, 2013 | # | Reply

      For the testing maybe you want to try Robolectric. It eases the pain when unit testing classes that have a context dependency. But be aware, it is really slow.

  • ColdSnickersBar 6:28 am on November 9, 2010 | # | Reply

    That (screenshots) was supposed to be a link to: http://coldsnickersbar.imgur.com/screens

  • Android development company 6:57 pm on November 19, 2010 | # | Reply

    You yourself have seen such a thing? Interestingly for the iPhone is the analog? It’s not that simple.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 223 other followers

%d bloggers like this: