3

I am a junior programmer who works as an intern(8 mths into the internship) in a team of 1(myself only) creating mobile phone apps & websites.

I have created an App that works exactly how it should & has some pretty cool features but the App fails to run on Android(the main target platform for us, it works on the desktop emulator but not on Android) due to the memory problems with large apps in the Mosync API(see the links for more info on the memory problem). The most demoralising aspect of the problem is that(as explained in the links below) the app crashes randomly & not consistantly so you make a change run it on the platform a cple of times & where something worked before it will now freeze then cause the app to crash(Android OS kills my app).

http://www.mosync.com/content/android-how-much-memory-too-much-memory http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/

I have invested 4 weeks in developing the app(an interactive calendar) & 5 mths in learning the Mosync API for apps that wont work on the platform.

My Problem: I have to decide between dumping the app & starting the app again in Native Android Java(I know Java) or severely reducing the the number of resources(.pngs) & features of the app(polaroid effect it produces) to make it work in the android platform. The end result will be functional but low quality(in terms of graphics) & simple.

What would more experienced developers decide to do & how would you explain this decision/recommendation to your non-technical boss?

Robert Harvey
  • 199,517
Mack
  • 31
  • the main target platform -- which kind of Android is that "main platform"? Smartphone or Tablet? Or both are main? or one of them is decided to ignore - which one? or one as main another as secondary? or something else? Congratulations btw - you learned two most important things in mobile dev: 1. that testing on emulator is not enough (hope in future you'll try to start testing at both emulator and real device as early as possible) and 2. most typical way to address resource limitations (your note on reducing pngs and effects looks spot on) – gnat Aug 19 '11 at 08:41
  • Next time you do it the other way round - make a functional version with all the cool features and only then start to add whistles and bells. – Ingo Aug 19 '11 at 11:55

2 Answers2

2

I'd do a translation to Java. Save as much of the application architecture as you can. With mobile apps in the particular, presentation really matters and crisp visuals help a whole lot on a small screen. Take all the ideas that work and re-craft rather than tearing down the code base.

I did that with an iOS app and I didn't finish the second build before the class I was working on it finished. I wound up with a mockup movie done by manually manipulating the UI in the GIMP and then stringing each frame together. I don't recommend that method for real production code. I may have gotten an A for effort and a good report but I don't think you'd get the same reception.

So if you know Java, run it to Java as well as you can. Scaling down would likely be less effective in the long run than a slightly buggy but stable initial release that looks nice and runs mostly stably with some hitches than a app that looks awful and runs smoothly. Bugs can be worked around, lousy design is harder to correct. Strip it to the bone if you have to but try not to throw it away completely.

As far boss goes, ask something like this question: Would you rather release a low quality product soon that might make us look shoddy or a more pristine app later that makes us look awesome?

1

Dunno about Android, but often you can resort to palette based PNGs (they come closer to GIF than to JPG), compression and that sort of things. See where you can reuse stuff. You don't need a whole button if you can combine it from ultra small PNGs. Some things can be generated dynamically, gradients etc...

How much memory does the stuff use? What's the target amount? How heavy is the code/resources?

Coder
  • 6,968
  • 5
  • 38
  • 49