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.
