Hacking A Startup DroidRules HackedLabs Posts My Google KnolsEveryone has been looking for a sales channels similar to Apple AppStore. I found an innovative one that involves the context of the mobile device user in the process. It has some apis to access, but its not bad in that the coding time is somewhat small.
Now, to find a firm in Chicago that needs android development on a weekly basis so that I can use free time to put into action.
Here is what the WabashDashboard looks like:
It was kept simple without use of grails-groovy, django, etc as wanted developers to be able to use it on laptops as well as desktops. I just used some effective iframes to make it real damn easy in operation.
The last part of Wabash to add is the ability to execute MonkeyRunner python scripts. Basically Monkeyrunner allows you to install the app and feed mocked user input to app and take screenshots and also install the android test project for the app as well within the same script and run tests.
MobileReview is claiming that Nokia also signed up to produce an Android handset in early 2012. You might think that on the whole that might be false. But some things do not match.
The CEO’s memo and speech mentions that Nokia is getting out-marketed in 3 distinct areas; low cost feature handsets, middle cost smartphones, and high end smartphones while mentioning Apple, Android, and RIM. Yet the slide shown shows WP7 taking the high end and middle smartphone market from Nokia and that slide doe snto match market data.
The words used to describe the Nokia-MS partnership echo other MS mobile partnerships in which the OEM used MS to put out a WindowsMobile handset while at the same time putting out a competitor OS smartphone and later put their weight around that competing OS. Those OEMs who have taken that path in the past are HTC, Samsung, SonyEricsson, Motorola, and several others.
The indication that this would be true would of course be Nokia joining OHA. At this point I do not see any indication, despite MobileReview’s claim, that its true.
You might be wondering why I would spend so much time on integrating things via an ANT or Gradle build tool. The whole idea was to be able to do full application testing from beginning to end similar to the way OEMs do framework testing. In other words the developer should be able to run multiple devices and emulators through suite of tests that include TDD and BDD unit tests among other UI tests and should get back test reports and screen shots.
Now we all know about Monkey UI Exerciser which is a small java api to drive UI testing events. That is not what I am referring to as we need some type of framework. So what do we need:
-run multiple devices or emulators
-run the application
-be able to interact with ADB
-generates UI events and screenshots
Something has popped up in that I have not noticed it before, its called Monkeyrunner. Its a jython/python api/framework for driving both the android emulators and android devices. Is has a plugin system for using java to extend it and we have an ANT jtyhon task via dbmstools.
With this amount of control to run full set of test suites on an application on multiple emulators/devices why would you choose robolectric over robotium? Sure you get speed of test execution bu than you are sacrificing being able to run a real full tests suite.
But what about not enough Mock objects? Let me tel you a secret about android mock objects. A lot of them are not fully documented yet in examples which is why you really should explore android source code as you can find all sorts of useful mock testing objects that the android framework developers use.
Basically this means that the individual tests are using the device or emulator to run along with android-mock and robotium to provide TDD and BDD gets implemented using Instinct during your coding sessions. Than at the end of the day you are using Monkeyrunner to run a suite of tests as jtyhon/python script that runs a suite of tests on the application across multiple devices and or emulators.
There are enough emulator add-ons provided by SonyEricsson, Samsung, and Motorola that while it does not cover ever device it does allow you cover enough of the android device space among popular handsets to catch most of the bugs that may be device specific.
Evidently Monkeyrunner has been in the SDK since 2.0 but I did not notice it before. Okay, thus I now know why I should be using robotium over robolectric.
Ah I think Google plans a nice x-mas present for android application developers in the form a new and improved ADT plugin. Visual Editor now has drag and drop! Proguard fully included. Heirarchy viewer no longer regulated to command-line as you will view it using the new ADT plugin. And also clicking on lines in logcat takes you directly to code.
Dario Laverde has more coverage at his first blog post.
I am going through determining if I author an android dev book on android 3.0 thus here is what I have thus far in what android 3.0 will contain:
-finalized USB/Blueooth apis beyond the unpolished ones now in place.
-VOIP/SIP apis finalized?
-more hooks to hardware/software buffers audio/video, etc?
-update of webkit
-UI apis fully ported to all public from the mix of pubic/private apis currently in the UI area.
-new JetEngine release
-OpenGL ES 2.0 support
-Tablet optimizations
-some more device administration apis
-more NCF support in form of new apis
With Packt Publishing attempting to recruit me as an android 3.0 development book author and an android training opportunity position opening up in downtown Chicago, I once again have the opportunity to think about how android development should be taught in class form and book form.
Its not that there are not stellar resources already out there such as Mark Murphy’s, etc. Its how do you reach the maximum audience about the power of this new mobile platform through developing code in java/C++ and js/html/css.
First, mobile programming is different. Some of the differences is that its a casual application that does not operate or run-all-the-time. Its security context is around both user authentication within the mobile operator system and the google user system. Its not big screens like the server or desktop.
There are also other differences as well in that not every member of the audience is java programmer as many web programmers are switching to android not just the PhoneGap applications but also the more heavy duty in CPU cycles applications such as games, etc. My respectful disagreement with Markana Inc. was that there is enough basic java patterns in android java programming itself that one could use the android device to teach java.
In android java we use a modified mobile definition of singleton from the javaME area. That theory of why we use it is still valid java programming technique. The android mobile platform uses callbacks. the callback pattern is of course acting as a program pointer, something in java we do not have at the moment. The same pattern and theory are found in complex java systems on the enterprise side.
There are also such things as teaching the development process such as debugging, unit-testing, BDD and TDD, and of course best practices in dealing OEM-device-differentiation(press calls it android fragmentation). Than we have the subject of adding a native library to extend android to be able to use in an application.
Hopefully I get an opportunity to explore these subjects shortly.
Joe Hewitt, funny the complaints about open coming from a Facebook developer, the same firm troubled by privacy gaffles, not being open, etc.
Lets back track a bit. Other OSes claiming open in mobile devices. Symbian, at first Symbian source tree was not accessible and viewable by outsiders much like Android. JavaME, same deal. You see folks, its normal in mobile operating systems and in fact in any operating system with multiple stakeholders to at some point in the incubation period for the master source tree to be not viewable to outsiders.
The claim of it does not have this or that so must not be open is a bit of FUD to distract us from discussing other issues such as the consumer should have a choice in OSes, mobile operator device/service plans, etc without shackles of any OEM or Mobile Operator and Apple’s policy of locking down the consumer is somewhat wrong and miss-guided.
I did some hacking yesterday with Calculon in a attempt to see if it could be extended similar to robotium. Not possible, robotium is the best option..sorry MK(Calculon developer). Thus, we have a IDE plugin or build that runs all the tests at one time and completes a code coverage report along with a DSL syntax to reduce the complexity of writing unit tests.
It will not be as pretty as say Spock, but still it reduces test writing expertise to something manageable.
But Android emulation is unique in that we have to start up anew AVD to test a different device model. The obvious next step is to get some way to start and stop the AVDs in your emulator inventory and run install-app and tests each time and produce test reports for each device model.
Apache ANT is too brittle of DSL to be flexible enough to work as a work-flow testing scenario. This might be an ideal situation to use Gradle in as it uses Groovy’ DSL with the ability to run/execute ant tasks/targets, maven stuff, ivy, etc.
Dependency Injection vs Mock wise I do not see a need in testing to resort to DI if you have Android-Mock available. But maybe some developers prefer to use DI rather Android-Mock, it just seems that yuo are moving your focus away from tests up the DI chain if you pursue that route.
Gee, be nice if testing was easier and with the influx of new frameworks does not make it any easier. The major reason why the average android developer does not unit test from the beginning(TDD) is that in any Virtual Machine mobile environment you run into situations where certain objects are not accessible to test.
Robotium and Calculon attempt to reduce the complexity by overlaying DSL concepts to come up with a new syntax to testing. Than we have droid-sugar/roboelectric which brings different style mocking to the area.
My thinking is why not combine the android port of easymock(Android-Mock) with some DSL syntax and it allows me to re-enforce my android internals knowledge. Plus the problem with mocks, is that effective mocking is on device/emulator the way Android-Mock implemented and with mocking on JVM rather than Dalvik you are doing a lot of extra steps for less effective results.
So AndCalculon is a polite fork of Calculon to integrate Calculon with Android-Mock and see how far I can take it. I will publish more later this week with the bitbucket.org link.
MobileBytes 