On Fri, Nov 20, 2015 at 6:19 AM, Justin D'Arcangelo <[email protected] > wrote:
> First off, I agree with David that we should be focusing on web > components. Having worked with them extensively over the past few months, > they add tremendous value in terms of code reuse and general code > cleanliness and encapsulation. > It is not a big surprise that I agree with many things Justin says. But I want to pile a bit on Web Components beeing a magic answer. As stated in the Architecture Proposal <https://wiki.mozilla.org/Gaia/Architecture_Proposal#Disclaimers> since the beginning: "This model is not about using x, y or z. It is technology agnostic and uses very basic primitives of the Web. Various technologies can be put on top of that (module UI, React, Web Components, etc.) and can actually be benchmarked with real data from users using Telemetry." The goal of the architectural changes which are proposed is *not* to enforce a UI solution. So it sounds strange to be able to replace all the proposal, which is a set of different pieces (aka Service Workers, Data Sync, Telemetry, ...) by a single answer. Especially one that is so highly UI related. Now if we want to dive in the UI world, yes, a component system is definitively something we should all be looking at for *consistency*, *maintainability* and *performance*. What this component system should be, is not part of the proposal, specifically to avoid the confusion between what components are used for, and what the proposal is about. Now, it is understandable that Web Components is the default choice of many Gaia developers as a component mechanism. I would even validate the choice, if we do have dedicated raptor tests to validate their performance and ensure they do not regress over time (which is often the fate of a code that starts small and slowly by slowly get more features). Without raptor test it could not be proven that they will answer the *performance* criteria over time. Having a dedicated set of people that works on it, is definitively part of the plan that nobody knows but is the companion of the new architecture proposal: Architecture Transition Plan <https://wiki.mozilla.org/Gaia/Architecture_Transition_Proposal#Toolkit_Team> But it would be a shame to focus all our efforts in something that a third party may not even consider. If someone wants to ship a FirefoxOS powered device, it may rewrite all the UI, or just some parts, to please itself or its own UI/UX team. This custom solution may use a completely different framework, like React for example. If all our efforts has been focused on Web Components, all our work will basically be garbage for them (even for us if one day someone prove that a new UI framework is way more modular and performant). This is why defining a clear backend API that can be easily documented is important. Beeing able to prove that the backend is not tied to the UI at all is important too (this is one of the reason of beeing able to run it in a Worker, you can prove it does not rely on DOM apis or front-end specific logic). This is why offering caching APIs via Service Worker, not tied to a specific UI framework too, is important as well. To ensure that whatever framework is choosen, people can benefit from caching to help performance. This is why Data Sync is important. Whatever UI framework is used, users will get their datas. Etc... Vivien. > > However, web components only solve our problems on the surface in the UI > of our apps. The Gaia apps contain an enormous amount of complexity and > business logic that is not in the UI. For instance, the Music app needs to > use a complex metadata parser in conjunction with DeviceStorage and > IndexedDB to scan and store the contents of a user’s music library. What > NGA brings to the table, in this regard, is the ability to craft an > easy-to-consume developer API for the app. When we talk about separating > the front-end from the back-end in terms of “NGA”, we are really talking > about defining this developer API for the back-end and exposing it via an > HTTP API. This allows a traditional web developer, who is used to working > with server-side HTTP APIs, to jump right in and get up and running. > > In the case of the Music app, you can see the full list of HTTP APIs here: > > > https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/view.js#L10-L54 > > As for the front-end of things with NGA, our “views” are simply mini-apps > themselves. A single “view", at the very least, is just an HTML file to > define the view’s markup end a JS file to wire up the DOM and call the HTTP > API in the back-end. > > This past week I started experimenting with adapting the Music app to work > on TV. Within an hour, I was able to just drop in a couple new “views” that > were TV-friendly versions of what we have in the regular phone version of > the app. Specifically, the Music app normally launches to the “tiles” view > and is obviously reliant on touch events for tapping on albums to start > playing them. This needed to be wired up a little differently for TV > because we needed to be able to use the arrow keys on the TV remote to move > the highlighting “cursor” around from album-to-album. In a very simplified > nutshell, here’s what the “tiles” view needs to do: > > - Perform an HTTP request to the back-end URL “/api/albums” > - Loop over the response from the back-end and generate the HTML > - Attach an “onclick” event handler for the tiles to start playing the > album > - To play the album, we perform an HTTP request to the back-end URL > “/api/queue/album/{album_id}" > > As you can see, these look very much like things your average web > developer would be familiar with. So, to do a TV version of this “tiles” > view, I simply created a copy of the phone “tiles” view into another folder > called “tiles-tv”. For the TV version of the “tiles” view, the operations I > needed to do were very similar: > > - Perform an HTTP request to the back-end URL “/api/albums” > - Loop over the response from the back-end and generate the HTML > - Attach a “keydown” event handler for moving the focus highlighting > around between tiles > - When the user presses [Enter], we perform an HTTP request to the > back-end URL “/api/queue/album/{album_id}” > > I was also able to provide a completely different CSS stylesheet for my > TV-optimized “tiles” view. This was also extraordinarily easy because the > regular phone version of the “tiles” view has its own CSS file that only > deals with styles related to just that one view. > > The key takeaway here is that defining a clear and easy-to-use HTTP > back-end for our apps is extremely helpful in achieving a very clear > separation of logic between front-end and back-end. It also provides a way > for regular web developers to jump in and customize the front-ends of our > apps without having to understand all the complexity that we deal with in > the back-end. The other important point to note is that the NGA method of > separating our “views” in the front-end allows us to swap out entire > screens in our apps wholesale. Our “views” are really just simple > “mini-apps” themselves and because of this, I firmly believe that this > architecture will help us take on unknown form factors in the future. > > -Justin > > > On Nov 19, 2015, at 11:38 PM, David Flanagan <[email protected]> > wrote: > > I've been thinking a lot about this thread in the context of Ari's talk at > the All Hands meeting yesterday. We're working on an OS that has to run on > smartphones, smart tv's and other form factors tbd. Ari asked us to focus > on portability, and that obviously will be key to our ability to run on > different form factors. > > I had something of an epiphany today: In the future, teams inside and > outside of Mozilla will build devices that run FirefoxOS and will create > products that provide true user value and delight. At this moment we don't > know what those products will be. So for core FirefoxOS developers, our > users are these future product development teams. We need to be building an > OS that is so fast and flexible, so portable and performant that product > developers will feel delight using our platform. > > With that in mind, I'd like to suggest that we'd be better served by > focusing on web components than by working on NGA. > > Converting our building blocks to web components and then refactoring our > apps to use those components and to be based on higher-level web components > will give us much of the modularity and portability that we're seeking from > NGA, but at the same time, it will also create a high-quality library of > reusable UI components that third party app authors (including those who > are embedding FirefoxOS in new products) can use to more easily create apps. > > David > > On Fri, Nov 13, 2015 at 9:40 AM, Wilfred Mathanaraj <[email protected]> > wrote: > >> Hi all, >> >> Given the Music app splitting we have done in time for 2.5 we want to >> move ahead - I think it makes sense to be executed in a “train model” >> fashion. >> We should start from the top of the list and work through the list. >> >> When I say splitting of the apps, we are looking for the following >> activities to be done: >> 1. FE/BE split >> 2. Split views >> 3. Page transition >> >> Why did I choose the priority below? - for now we have 2 products that we >> work on: smartphone and TV, but moving forward we need to investigate what >> are the products that make sense for us and when we enter the connected >> devices market 3rd party developers need to be able to develop differing >> views for our core apps. >> >> With this is mind we went through some exercise to define a priority for >> the apps to be ported to the updated architecture. >> >> Priority list: >> >> - *Settings* - this is a key app for any product mozilla may be >> planning to release; different apps will have different needs to display >> information to the user in the settings >> - *Camera *- again a key app for a lot of the modern devices >> - *Contacts* - everyone wants to have contacts on their devices - but >> they need different level of information - creating differing views is >> going to key here >> - *Calendar* - as with contacts its critical to have differing views >> but not as high priority as contacts >> - *Gallery* - another core app that every connected device may need >> to have >> - *E-mail* - typing emails on smaller devices will be a problem and >> therefore creating readable email view may be needed for some connected >> deviceds >> - *Calculator *- table stake app >> - *Clock *- table stake app >> - *Browser *- one of core mozilla apps but a table stake app for some >> of the connected devices >> >> >> Some of the engineering teams, who have already worked on this split, >> will be reaching out in smaller teams to discuss best practices and quick >> wins for this activity. >> >> BR >> Wilfred >> >> --- >> FxOS Product Management >> Mozilla Corp., UK >> >> >> >> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> >> > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
