Considering BOINC for Android do you really want to reinvent the wheel ? There is already working and very convenient BOINC implementation for Android-based devices. It's NativeBOINC. http://nativeboinc.org/site/uncat/start . There are few projects working under this implementation, MilkyWay and PrimeGrid (and not only) including. The sources are publicly awailable on Github: https://github.com/matszpk/native-boinc-for-android/ I would strongly recommend to join forces and improve and support that existing app under Android OS.
Воскресенье, 6 января 2013, 11:10 +01:00 от Joachim Fritzsch <[email protected]>: >An important aspect to have in mind is: >The Android platform is very restrictive to what a developer can influence >(i.e. deciding where to install, or accessing a directory different than >application directory). Hence, designs that seem trivial on a desktop OS >can be very challenging to realize on Android. > >Anyway, I am afraid, my mind was set on the technology aspects rather than >the user experience. > >Let us come up with the *ideal* user experience and I will try to sketch up >an appropriate architecture from there! > >install scenario 1: volunteer hears about project, wants to get the Android >app. >a1. volunteer searches & downloads project branded application from >appstore. >b1. project app checks whether BOINC is installed. if no, app prompts >"requires BOINC", with BOINC logo and link to download BOINC from appstore. >c1. project app takes user through attach process (i.e. register project >account, or sign in existing one) >d1. as long as this particular project is attached to BOINC, project app >opens BOINC app instead, or refers to it. > >install scenario 2: volunteer knows about BOINC and wants to get the >Android app. >a2. volunteer searches & downloads BOINC application from appstore. >b2. BOINC app let's user attach a project. user needs to specify which one. > >from there: >e. volunteer controls BOINC behavior through BOINC application >f. upon de-installation of project app, BOINC app prompts to detach project. > > >=> consequences: >- BOINC needs to be present in appstore. And is responsible for its Android >app! >- BOINC app holds client and offers most of manager functionality. >- project apps allow projects to be present in appstore and to ease the >attach process. >- project app is light-weight and easy to handle for projects. >- full and intuitive(!) multi-project support. consistent experience. > > >comments, please! > > > > > > > > > > >On Sun, Jan 6, 2013 at 12:43 AM, David Anderson < [email protected] >>wrote: > >> Joachim: >> >> Yes, that's the intended architecture. >> The installers may have the names and icons of particular projects >> (e.g. Einstein@home) or account managers (e.g. GridRepublic). >> However, they should install the BOINC client and the GUI >> in a project-independent place (like /usr/bin/boinc). >> *It's critical that there be only one BOINC data directory, >> and one copy of the software*. >> >> We need to decide how things should appear to the user >> if they add N projects. >> Should it look like they're running N apps? >> >> My inclination is: no. It should look like 1 app, >> and the icon for it should be project-neutral (e.g. the BOINC icon). >> >> This suggests that at install time, >> we show the user a splash screen saying that >> 1) Einstein@home (or whatever the project is) is based on BOINC; >> 2) click on the BOINC icon to control Einstein@home >> 3) you can add other projects if you want. >> >> -- David >> >> >> >> >> On 04-Jan-2013 8:00 AM, Joachim Fritzsch wrote: >> >>> Hi! >>> >>> I want to propose an architecture change for BOINC on Android. >>> >>> The initial design combines Client and Manager in the same Android >>> application. >>> Which, due to the isolation of application on Android, leads to problems >>> when a >>> volunteer installs several BOINC-based applications - which seems not >>> unlikely. >>> >>> A possible solution is, to split Client and Manager back into different >>> Android >>> apps: >>> >>> - generic Client as a rudimentary Android app. Does not need to have a >>> user >>> interface, i.e. background service. A few lines of Java code, that trigger >>> ARM-compiled Client at boot time. >>> >>> - (potentially multiple) project-branded and -maintained Managers, that >>> check >>> for presence of Client upon installation (package dependency) >>> >>> @David,Rom: What are your thoughts on this? Is it possible for you to take >>> charge of such an Android Client in the long-term? >>> >>> Joachim >>> >>> >>> >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
