Hello, I agree with Gustavo. In this case we shouldn't add new modes of operation for application execution until the ones that we are required to support are in place. The insight we gain implementing the required bits help us creating new things later.
Cheers, Caio On Tue, 2014-01-07 at 19:50 +0000, Barbieri, Gustavo wrote: > Hi, > > This proposal tries to do too much at once: support Tizen, introduce new > concepts and so on. Please consider simplifying it to do what is required > first and then plan to introduce new concepts. > > The Picker example, for instance, doesn't work like in that document with > Tizen. In Tizen the only way to add another application's view to current > application is if you create an "ug" (UI gadget) that is actually a library, > this will create a widget instance in the application process and push it to > the current window UI stack (no interaction with the WindowManager). > > The only cases you start one application with a bundle is to start that > application in some state, for instance start the phone dialer with a > pre-populated number, or start "messages" with the compose screen and some > fields populated, etc. After doing this via AUL you lose connection with that > application, the window manager will show 2 windows, the task manager will > show two apps, etc. > > I guess you tried to match what Android does, with their Activity and > different launch modes (default, single-top, single-instance...). Thus let's > keep those out, focus on the basic requirements. > > All in all I'd also choose a different work to do. As Francesco and others > pointed out, Tizen and Android diverges in supported features. Tizen, for > instance, doesn't provide the basic as messages and contacts. These are > simple to implement, design is straightforward and all, but requires some > manpower as it's lots of code :-) > > -- > Gustavo Sverzut Barbieri > Intel Open source Technology Center > > > > -----Original Message----- > > From: Crosswalk-dev [mailto:crosswalk-dev-bounces@lists.crosswalk- > > project.org] On Behalf Of Long, Xiang > > Sent: Tuesday, January 07, 2014 6:47 AM > > To: Oliveira, Caio > > Cc: crosswalk-dev@lists.crosswalk-project.org > > Subject: Re: [Crosswalk-dev] Intent to implement: [Tizen] > > Application API > > > > Thanks for the comments. I summarized some key points below. > > > > - Currently, Tizen doesn't support "Activity-Task" like page > > ownership. As I tested on Tizen2.1, pages are binding with their > > original app. > > > > One issue of this model is: when user resume an app which was > > calling another app's functionality, the caller page will show other > > than the callee page. > > For example, a gallery app provides "pick" picture service. An user > > may resumes his Facebook app after a phone call, however can't find > > his previous "pick" photo page. > > The same issue happens when user/system kill an app. > > > > With AppContext(contains a page stack) when user open/kill/resume an > > app, he is open/kill/resume the AppContext of that app. > > Pages from that app can belongs to other AppContexts, and these > > operations will not affect such pages. > > > > - Thanks for mention the native apps, the design doc only considered > > the web apps(legacy & XPK). > > It seems we need system level modification to support both native > > and web apps. > > > > So I think currently the MAIN question is: do we just need to follow > > Tizen2.1 behavior? If yes, the AppContext stuff can be removed. If > > no, the native/web behavior will not be aligned. > > > > - For testing, app samples and xwlak-launcher messages, I think I > > can provide them when we got the consensus on the above question :) > > > > > > > -----Original Message----- > > > From: Oliveira, Caio > > > Sent: Tuesday, January 07, 2014 5:31 AM > > > To: Long, Xiang > > > Cc: crosswalk-dev@lists.crosswalk-project.org > > > Subject: Re: [Crosswalk-dev] Intent to implement: [Tizen] > > Application API > > > > > > Hello, > > > > > > On Mon, 2014-01-06 at 09:23 +0000, Long, Xiang wrote: > > > > Long term plan: AppContext support. For details please check the > > design doc: > > > > > https://docs.google.com/a/intel.com/document/d/1n08dzcl3fawRW2Eccg95 > > TC > > > 6DApe6RoAdUDqaZwNM8dI/edit# > > > > > > I have added some comments and questions to the design doc, please > > take > > > a look at them when it's possible, I won't replicate them all > > here. > > > > > > More questions: > > > > > > - I'm not sure that Tizen WRT actually supports an "Activity"-like > > > semantics, i.e. one app can load a "view" from other app (in our > > case a window, > > > in Android's it's an "activity). Have you tested this? > > > > > > - Why do we need to keep the stack structure for each AppContext? > > Which > > > operation > > > will make use of them? > > > > > > - Since we ask AUL, we can launch native applications, and I > > expect that we can > > > use > > > appcontrol with them as well. Is that correct? That means that our > > > "AppContext" stackes > > > will be "incomplete". How do we deal with that? > > > > > > > > > In my opinion things this proposal still needs work and besides > > the comments > > > in design doc and the questions above, some more general comments: > > > > > > - How will we test this feature? How can we make sure these APIs > > are > > > working as expected (i.e. working like Tizen WRT)? > > > > > > - Would be good to turn the example in the design doc into a real > > > working example, so we could see the "AppContexts" in action on > > Tizen > > > WRT. > > > > > > - Give more detail to what information needs to be passed from/to > > > the launcher process. Regardless of the implementation, the set of > > > information that needs to be communicated back and forth will be > > the same, > > > so this is not wasting time into details that might not be used. > > > > > > > > > Cheers, > > > Caio > > > > _______________________________________________ > > Crosswalk-dev mailing list > > Crosswalk-dev@lists.crosswalk-project.org > > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
