Yes, we're aware of those projects and using some of their work. -- David
On 06-Jan-2013 9:07 AM, Raistmer the Sorcerer wrote: > 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] > <sentmsg?compose&[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] <sentmsg?compose&[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.
