Notes on how to proceed with (Android) UI

Developers
2012-03-17
2013-05-29
  • Jyrki Kuoppala

    Jyrki Kuoppala - 2012-03-17

    A couple of notes

    * as for the proposed split

    I wonder if a split of the code between J2ME / android s needed / a good thing at the moment. Easily a result of the split could be that J2ME version ends up abandoned. Rather, at least for now, I propose we try to keep the code base together and see how it will work. (possible create a separate android dir/tree for Android parts)

    * How to improve the Android UI?

    The next logical step to make the Android UI easier is to add some ok/cancel buttons (with perhaps graphical icons) to at least some frequently used screens like entering waypoints. However, I'm not sure I want to go too far with that. Doing major work with J2MEPolish CSS machinery to make the J2MEPolish appearance on Android look good does start to seem like it might not be too good an investment. Rather, I see a couple of alternatives:

    a) rework gpsmid/ui/* to create data structures for the various setup / function screens, then create backends (e.g. j2me backend/ j2me w/CSS backend / menu backend / Android native backend, later perhaps some other platforms). The backends would then translate the data into each platform.

    b) rename gpsmid/ui/* to gpsmid/ui/j2me/*, possibly create an interface layer gpsmid/ui/* which would allow us to gradually replace the J2ME functionality with native Android UI code in gpsmid/ui/android dir. Start populating the android dir. Later, UI support for other platforms could be added.

    While a) is theoretically tempting (same menu structures could be used for text menus, icon menus, Android views etc.), I suspect the better way to go in practice would be b). Then the J2ME UI could be left in place, and new features could be added to Android UI without worrying about the small J2ME device limitations.

     
  • james

    james - 2012-03-18

    The original plan was to have:
    for each platform a native source directory and a common source directory for i.e. J2me, Android, Java on Desktop a.s.o.
    to split it by UI means seems to be not so helpful. The Common src dir should hold everything like routing, read data structure, all parts that interact with the device should be in the device specific src dir.

    with seperate src dirs we are able to use i.E eclipse and declare i.e Common and Android as src dir. So that eclipse can operate as normal. The other (J2Me part) will then simply not in the build aand classpath for the IDE.   

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks