GSOC-2014: Some ideas about Android

edited March 2014 in Summer of Code 2014

Hello everyone! :) My name is Imil Ziyaztdinov, 18, and I'm currently in my 2nd year of studying Computer Science at the Higher School of Economics in Moscow, Russia.

I've been using Processing a lot during my study to accomplish most programming-related tasks so I was really excited to see the project among selected for GSOC this year. Now I'm trying to find out what can I do, and, since Android development is my main focus for more than two years, this was the area that caught my attention.

Since I'm just starting to discover Processing on Android (haven't used it before), I would really appreciate if someone more experienced could give some comments about ideas that came into my head at this moment, maybe some of these ideas are already implemented/already being implemented/not worth implementing :) (I'm also thinking about working on some ideas already published in the wiki on the Projects-list page, especially first one about device API usage samples looks interesting).

So here are a couple ideas that I want to get your feedback on.

1) Some simple AndroidManifest editor GUI, probably on top of currently offered Permissions selector - a tool where users could give a title for the application, change app version, select launcher icon (i know, you can currently place 3 icons in the sketch folder which will replace default icon, but we could possibly provide a simple editor similar to what Android Studio has), select compatible screens, and select needed permissions.

2) As far as I understood there's currently no easy way to access Android resources like strings/drawables/xmls etc, which I think would be nice to have cause it makes possible, for example, to translate the application into different languages. So the idea is to allow to easily add such resources, and probably (do you think it's needed?) introduce something like "Resources editor" where users could add things like strings for similar languages, drawables for different screen resolutions, etc.

3) Not a huge and significant change, but I think it would be great to be able to select build target SDK (currently hardcoded to 10, right?) and minimum supported SDK.

4) I have noticed that it is not possible yet to export signed package right from PDE - is there somebody working on this? If not I think it's a good idea to implement this too.

So, I think that's all for now, I'm going to browse through the forums to see if there are possibly any user requests, but again, I would appreciate any feedback on these ideas at this moment.

Thanks in advance, Imil

Answers

  • Hello Imil, thanks so much for your posting your ideas for GSoC!

    Right now, we haven't had much time to work on the Android mode, so it would be really great to have someone contributing to it and implementing missing useful functionality. Did you take a look at the android page in the processing wiki? it also contains relevant information.

    The AndroidManifest editor GUI could be probably useful as a tool. While about 2), not so sure if it is really needed - at least from the Processing environment (PDE) - since the idea of using the PDE is to simplify the development process by minimizing complex setup, project structure, etc. For example, sketch resources should always go into the data folder (android icons are an exception though), and this should be consistent across modes. If you need more advanced resource management, you can always export the sketch as Android Project, and access to the complete folder structure including the resources.

    3) is tricky, the SDK 10 requirement was hardcoded a while ago in order to maximize compatibility across most Android devices, maybe this is time to review that decision, but needs some careful discussion.

    Yes, the export signed package functionality is missing, and I don't think anyone is working on it right now, so it would be great to do. If you take a look at the issues page for the processing-android project, there are other open issues that are worth looking into, I'd highlight this other one as well: remove android SDK installation requirement.

  • edited March 2014

    Thank you very much for your comments! :)

    I think I agree with you on 2), it's more important to keep consitency across modes and simplicity.

    As for 3) - well, it seems leaving 10 by default would still be the best option, those who don't care about build targets would still have their sketches built for the vast majority of available devices, but some easier way to change that than recompiling Processing is really needed imho, probably just a simple selector somewhere?

    Thanks for the links, added these two ideas to my list, still going to look through the forums and the issues page to find some more.

    A couple more ideas I would like to know your opinion:

    1) It isn't possible to select which device I want a sketch to run, if more than one is connected, right? It seems to choose the first available from the list. It would be really useful to be able to choose the device, probably combine 'Run on device' and 'Run on emulator' options under single 'Run' button, which would either instantly run a sketch on emulator if no devices are attached, or show device/emulator selection dialog after build like Android Studio does, for example.

    2) Is there somebody working on PDE GUI localisation? (I know this is not related to Android, but I actually found about this from the Android issues page :) I (probably) would like to pick this idea too, if noone else will, cause I think it would be great to have a multi-language user interface.

    3) A small question about 'Additional Libraries to extend support to mobile device APIs for networking, mapping, and reading sensor data.' idea from the project list. As the android page in the wiki says there are already some libraries and examples available for these. I just want to understand the idea better: new simple examples for these should be written from scratch, so they could be included with the download, or only examples that would cover parts not already covered by those examples available, if any?

    Thanks!

  • From what you have described so far, seems that your proposal would mainly consist in updating the PDE in the android mode in order to implement important missing functionality (like the export signed package), and add some new functionality (manifest editor, SDK switch, device selector). All of that (and maybe only a subset) would probably take all the three months available for coding, so it is important to prioritize.

    GUI localisation is also very important, but that alone could easily be an entire proposal by itself, at least from my perspective.

    Regarding the additional libraries idea mentioned in the wiki, I think it mainly consists in the following: first updating and expanding the examples in the sensors folder (currently it only has accelerometer and compass) in order to expose other functionality available in the Android SDK (like networking, mapping, etc.) through a simpler, Processing-style API. Once these new examples are ready, the second step would be to package them as a collection of light-weight libraries. Not sure if the goal would be to bundle these libraries with the Processing download, or as separate install trough the Library Manager. Again, this idea could easily be a full proposal by itself.

  • Well, yes, surely I won't take all of the ideas I'm expressing here :) I'm just trying to gather as much information as I can in order to better understand what's needed and make a better proposal. I'm going to assess how much it is possible to be done once again when I write a proposal, but yes, most probably it would consist of what you summarized in the first paragraph.

    Thank you very much again for expressing your thoughts, it really helps a lot :)

  • hello friends,my name is Ajay and i m working person in india I just want to know that is there any possibilities to merge processing and android??? or we can say can we use processing to develop some app for android???

Sign In or Register to comment.