On Mon, Apr 2, 2012 at 10:55 AM, sasinda rukshan <[email protected]> wrote: > Hi Thomas, > > Thanks for the advice. > Shall I remake a proposal with the approach you suggested? Or should we > discuss furthermore how it should be done? > Am I correct to assume we are now focusing mainly on the framework and the > applications will be just demos as previous time. > > In the 1st proposal I was thinking of a main application that you can > plugin other parts such as bloggers and navigators... etc. All the > user/settings entered through the Settings of the main app can be shared > through the plugin apps. > If we are going to separate apps, settings data can be shared by the > database, Android Content providers or any other means android allows for > sharing of data. I am not yet technically efficient in Android to > specifically say what is better. Then other applications can set the > default settings,or override with app specific settings , where default > ones are shared among all apps. (another approach would be to have > a separate app to manage settings)
Not an Android expert either but at least it would be nice to have XWiki account listed as Android account and make them the standard way for an application to connect to an XWiki instance (unless the application use its own settings for some reason). The problem with having an application dedicated to managing setting for others is that you can't really indicate dependencies between applications on Android so that means the framework should know a commons place to store thoses settings, I don't know in details how Android account in setting are working but sounds like a good place for this. It's not that much that we plan to do ourself separate applications but for me the main target is to allow any application to easily communicate with an XWiki instance for whatever reason and even better if we don't code the application ourself, the goal is to make people use XWiki ;) The framework you described in general is still valid as a set of consistent libraries arround XWiki as I always seen it myself. The idea of an XWiki centric application with plugins is however still a good idea as platform to show off what the framework allows to do. > Does the proposal need that much of detail in it? Will my earlier proposal > suffice with the two ends moderated?. No need to details too much but indicating if and how you plan to allow applications to share settings, local cache when offline, etc. is important I think. You should directly write your proposal on melange since we now agree with the general idea (you can modify the details anytime you want). IMO a good practice given the short time is to describe the target demo application you plan to do (for example the blog) and make everything needed for this demo a reusable set a well defined and tested tools that would allow anyone to redo the same thing without much custom code like it has been done for what's currently in https://github.com/xwiki-contrib/android-client. > > Regards, > Sasinda Rukshan. > > > > > > > > On Mon, Apr 2, 2012 at 11:48 AM, Thomas Mortagne > <[email protected]>wrote: > >> I agree that it's impossible to do a perfect framework like that at >> once, that's why it's important to do it peace by peace and properly >> separate subjects and abstraction levels from the start. Now we have >> to start somewhere and in my opinion it's OK to refactor and >> deprecated stuff it as soon as something is starting to be too >> complex. The "advantage" with Android is that libraries can't really >> be shared (not yet at least) so it's not a big issue to break some >> APIs as long as you always provide alternatives since each version of >> the library is bundled with each application that is using it. >> >> On Mon, Apr 2, 2012 at 5:20 AM, sasinda rukshan >> <[email protected]> wrote: >> > Hi Thomas, >> > >> > I am very happy to here that you like my approach.Thanks. I was >> discouraged >> > to do approach 1 not only because it would take a bit more time and >> effort. >> > It was mainly because if I am doing such a framework future developers >> will >> > be depending on my framework, so if I do a, say not that good job I will >> be >> > making there time rough with a bad base framework. The only workaround I >> > see is we must talk with some experienced architects in the community and >> > come up with a good and salable base framework that provides simple and >> > intuitive APIs so that the usage of the framework will have a short >> > learning curve. In my opinion it does not take much effort to start >> making >> > a fully functional complex API.The case is the early developers that move >> > in to develop the framework will do a good job but later the framework >> will >> > become complex and they will be doing workarounds to present more >> > functionality from the framework making architecture degradation of the >> > framework. It takes a lot more effort and thought to make a fully >> > functional simple API(Which hides its complexity from the developers) and >> > make it scalable with the simplicity intact. It is not possible to come >> up >> > with the design of such a framework at once, we would have to re >> > architecture it at major versions. But it is important to keep the >> earlier >> > point in mind. >> > I like to have a scalable and simple framework that follows consistent >> > patterns so later developers who scale up the base framework will have a >> > clearly defined scheme to scale it up, and will avoid add hoc manners of >> > doing it. >> > I really love to do this, so the developers who join us later will praise >> > us for doing such a well structured framework which is easy to build on >> top >> > of it and easy to scale from the inside. >> > If I am to do this, We can do some research on other application >> frameworks >> > and come up with a good initial design for our framework in the community >> > bonding period (After 10 th May. I am having semester end exams till >> that. >> > And I will be very much free being an intern after that.Internship is >> said >> > to be far less work than what you go through in a semester). Your base >> > connection framework is superb. We would let that foundation framework be >> > considered only about the connection aspects (providing APIs for REST WS >> or >> > RPC). We will consider how the rest of the framework is built on top of >> it >> > (approach 1 was only an initial idea there wasn't much thought behind >> it). >> > This semester I am taking up an optional course for software >> architecture, >> > I ll make sure to study well for it. I apologize if I am not replying you >> > soon enough. >> > Thank you. >> > >> > Regards, >> > >> > Sasinda Rukshan. >> > >> > >> > >> > On Sun, Apr 1, 2012 at 11:38 PM, Thomas Mortagne >> > <[email protected]>wrote: >> > >> >> Hi Sasinda, >> >> >> >> Glad to ear that you are interested in this project. >> >> >> >> I just read your proposal and I must say I like a lot the Approach 1 >> >> since the heart of the project for me is to make easy for others to >> >> build well integrated Android applications which need to manipulate >> >> XWiki datas. Applications built by us on top of it have mostly >> >> example/demo value for me. >> >> >> >> What you described is very complete and indeed probably a bit too much >> >> for the GSOC, but it would be good IMO to do something between the two >> >> approach. While the full framework is probably a bit too much in the >> >> time frame, only doing an application and not improve and extends the >> >> current framework would not be the best direction I think. >> >> >> >> An idea would be to lead the way to the framework you described and >> >> implement only the part needed for your blog application idea or >> >> another application the same way the previous GSOC built the current >> >> connector as a dependency of a demo XWiki client. >> >> >> >> On Sun, Apr 1, 2012 at 5:24 PM, sasinda rukshan >> >> <[email protected]> wrote: >> >> > Hi all, >> >> > I am Sasinda Rukshan from University of Moratuwa Sri Lanka. >> >> > I created a proposal for the Google Android XWiki Connector. >> >> > link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf >> >> > (failed to attach it to the mail and send as the mail bounced back >> >> alerting >> >> > the file is too big. : 603KB) >> >> > >> >> > Thank you. >> >> > Sasinda Rukshan. >> >> > >> >> > On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan < >> >> [email protected]>wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> I am Sasinda Rukshan from University of Moratuwa Sri Lanka. >> >> >> I have attached here with a proposal for the Google Android XWiki >> >> >> Connector. >> >> >> >> >> >> Thank You. >> >> >> >> >> >> Sasinda Rukshan. >> >> >> >> >> > _______________________________________________ >> >> > devs mailing list >> >> > [email protected] >> >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> >> >> >> >> -- >> >> Thomas Mortagne >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
