Deadlines are here!

It’s almost time for final submission’s and I’ve been spending a lot of time lately polishing the code and trying to make sure everything comes together in a neat way. However, there is still quite a good amount of work left for me this week, which I guess I should be able to complete. The good thing is the frontend of the app is almost ready with a few minor styling touches left here and there, which means that the major portion of the coding is done. However, there still is the issue of getting the backend to work properly with the frontend.

Documentation Woes

I’ve been working on getting the app to work with live data fetched from the WP servers via XML-RPC requests using enyo WebServices however, so far, it has been quite an uphill challenge for me as I’ve been unable to find any good documentation so far on getting the APIs to work with WebServices. The only documents that I’ve been able to find so far are a list of XML-RPC APIs for WordPress which however do not have any usage examples to work with, meaning I’ve to manually do a bit of trial and error with each of these get to understand how to work with them better. This has been taking up a lot of my time in the last couple of weeks which has been a bit troublesome for me.

However, the good thing in all of this is that I’m getting to learn a lot of things the hard way around, which means that I have a better understanding of how things work and how to implement things better. Also, my mentor is super helpful at times when I think that maybe I’m slacking a bit. I was a bit worried about how to make batch requests from the client to the server and couldn’t quite understand how to use system.multicall, [again because of lack of good documentation] so I sent him an email, and voila, he again rescued me by replying with quite a thorough explanation of how batch requests work! 🙂

Anyways, to summarize things I would say that all the offline components are ready to go and done, the only thing that I’m still working on is completing the XHR requests to the server via the WebServices. It’s still pretty nascent, but looking at the present status of work, I’m sure I can get it done within the deadline! 🙂

#firefoxos

A Sudden Break From Coding

After quite a long time, since the start of this year’s GSoC this was a rare week with me spending most of the time researching and studying various ways of tackling XHR requests via Enyo.js in a way that’s compatible with Firefox OS. Essentially, I had to study quite a bit to understand how exactly Web Services work in Enyo and what are the various implementation options available for it.

Using Firefox OS’s systemXHR APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.

For this purpose my primary focus has been on understanding how the enyo.WebService component can be used to perform XHR requests for the Firefox OS app. Turns out, that this is quite an easy implementation for Firefox OS. All that needed to be done was to set the app’s permissions within it’s manifest file as follows:-

“permissions”: {
“systemXHR”: {}
}

Then whenever a systemXHR is to be needed, I would simply add the ‘mozSystem’ attribute to
the XHR instance:-

var xhr = new XMLHttpRequest({
mozSystem: true
})

This pretty much handles the major requirement for such an app for Firefox OS.

Enyo Web Services

Basically enyo.WebService is a component that performs XHR requests; it acts as a wrapper for the Async subkinds enyo.Ajax and enyo.JsonpRequest, using these subkinds internally to manage HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. transactions. Since the WordPress APIs are XML based, the primary focus here is on using enyo.Ajax to retrieve all published properties of the enyo.AjaxProperties object. Hence allowing direct communications to take place via the app.

Current Work Status

I’ve already completed a significant amount of the background research required for the implementation of the XHR requests for the app. However, due to some unexpected personal problems I expect to be a bit slow at work this week, however, looking at the amount of work left, I am pretty confident of completing a basic working version of the app running by the end of the next week.

#firefoxos

Here’s a rather brief report of things that I’ve completed so far [in a very brief words] and things that I’ll be working on in the upcoming weeks:-

How the Car Assembly is taking Shape

I spent the most of last week, polishing, restructuring and moving huge chunks of code to complete the offline framework for the WordPress for Firefox OS app. Comparing the complete app to a car development analogy, what this means is that I have successfully completed most of the body work including the hood, trunk and body. Now the only things left are mounting the engine [i.e. the XML RPC APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to handle XML RPC requests and responses] and getting all the tricky pieces of wiring connected to the body work. This basically boils down to writing an enyo.WebService code to handle and format all incoming and outgoing XHR requests and responses.

Upcoming work to get things connected

I expect to spend most of the time this week studying the WordPress XML-RPC APIs and implementing them on the app via Enyo code. The one thing that I’m sure about is that I’m sure hit quite a few stumbling walls this week as I’ll be again chartering into personal unexplored territories. However, I expect to pick up things quite quickly, once I grab hold of how the XHR APIs and enyo can be brought together to work as one unit and get the app working with live data.

#firefoxos

Progress this Week

Until last week, my primary focus was on building newer components to make sure that all the primary blocks of the app are in place. However, starting with this week I started putting all the different pieces in their respective places.

My primary objectives for this week were:

1. Convert the Primary app menu from being just another page component to a sliding drawer component
2. Modularize the Composer UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. to get rid of the current Scroller layout and allow for more focus on the textarea.

Enter onyx.Drawer!

Onyx.Drawer is quite simply nothing but a simple Onyx control that appears or disappears with a sliding animation, based on a Boolean property.

This solved my primary problem of implementing a sliding drawer menu component for the app. All that I had to do was to change the menu component to a ‘onyx.drawer’ kind, along with few minor changes here and there and a bit of code refactoring, and we now have a sliding menu bar!

The fun part of this came next, when I realized that the same Drawer kind can be introduced within the Composer as well to help me with my second objective of this week. For this purpose, I went back to an earlier version of the Composer with the Settings button in it, and using the button itself as a boolean trigger to open a vertical drawer containing the post settings such as Status, Tags, Categories etc. However, after a bit of messing around with the Composer code, I finally had a much cleaner looking Composer UI with a more aesthetically pleasing looks to it.

Next Steps

This week I plan to work on the last remaining piece of the puzzle: the Login screen! Once it’s done I plan to move on to the backend apis/queries to replace the current hardcoded demo datasets to more real world datasets, sometime next week. Also, there’s a minor bug with the preview module that I’ve been meaning to get fixed for sometime now, that I want to work upon this week.

#firefoxos

Current Status

At the moment I’ve completed work on the base structure of the app, including a basic layout for the Posts, Pages and Comments Views, with a demo data source for each. Also, I’ve a built a basic menu dashboard to access each of the app modules, however, I’m yet to work on the styling part of each of these components.

To give a brief and concise understanding of the progress on the app so far, I’m going with a slightly different screenshot oriented reporting approach this week. Here’s a screenshot based walkthrough through the individual components for the app built uptil now.

Screenshots

Post List

Posts List

New Post

New Post Composer

Page List

Page List

New Page

New Page

Comments

Comments List

Dashboard Menu

Dashboard Menu

Remaining Work

The primary things that are left of the work at the moment are a few bug fixes for the Preview module apart from the development of the Login module and completion of the Reader, Notifications, Stats and View site functionalities. Once these are completed I would be focusing on implementing the connections between the app and the WordPress Servers to fetch live data. The last thing on my todo ist is the styling aspects of the app to beautify the look and feel of the app.

P.S.: Due to a sudden internet outage last night I’m a bit delayed in posting this weekly report.

#firefoxos

Those Pesky Creepy things called “Bugs”

Last week went a bit slow due to some unavoidable personal reasons, however, I managed to identify some major bugs that had cropped into the Composer Code. Most of these were basically layout related bugs affecting the general layout at varying device widths, however the two most significant bugs that are yet to be resolved via code were concerning the layout of the WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. toolbar and scroll-ability of the Composer page.

It seems that the best solution for the first problem would be to remove the toolbar from above the textarea and replace it with a floating toolbar over the onscreen keyboard. A few simple CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. tricks should be quite able to take care of this problem.

The second problem is a bit tricky though. Ever since I changed the layout of the composer to a single page layout, the scroll-ability of the page seems to have been disabled. This is most likely the result of using overridden fit-able classes, however, I’m yet to investigate further into this problem. I plan to take on this bug sometime later this week and get it done.

Developing the Pages Module

The next thing that I started with this week was implementing the Pages module. After doing a brief comparison between the Pages and Posts module, it was pretty clear that Pages is pretty similar to Posts and requires almost the same code with a bit of reduced functionality. The way I implemented this was by rewriting the same code as the Posts module with a few exceptions in the Composer functionality, mainly the removal of Categories, Tags, Status and Post Format functionalities from it.

Next Steps

The major work that I will be undertaking this week would be fixing the WYSIWYG and scroller bugs after the Pages module is completed. Once this is done, I would start with a few unfinished functions within the Preview module, and move on to a bit of Styling details.

#firefoxos

DEVELOPING THE NEW POST UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.
————————————————

Picking up work from last week, this week I finally managed to get over the initial inertia that had kept in check the pace of development. To start with I developed the new Compose UI based on the layout of the earlier WordPress for WebOS app, including the base components for the composer, i.e. Preview/Save/Draft/Publish/Settings buttons, headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. and footer toolbars, and the layout for a Rich text based WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. editor. Even though the underlying code for the base implementation was surprisingly easy and straightforward, it took me a bit of time to get hold of the whole process.

Long things short, it’s as simple as writing structured object oriented JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. documents once you get comfortable with everything Enyo has to offer.

REDESIGNING THE LAYOUT
——————————————

Once I was done with the basic rework of the Compose UI, the next thing that struck me was the fact that the earlier app was specifically designed with tablets in mind, meaning the earlier sliding layout was good for devices with higher resolution. However the primary target devices for Firefox OS being smaller smartphones, most have a basic 320x480px resolution. Hence, the earlier design layout, would just not fit in the display. Hence, what was needed was a change in the layout.

For this part I’m planning to use the same layout as is used by the current Android app. This would in turn result in two main advantages:-
1. Solve the layout problem for smaller devices, and
2. Maintain a consistent look and feel for the app across varying underlying architectures.

CURRENT WORK STATUS
——————————————

Currently I’ve moved on from the Compose module to other parts of the app. At the moment I’m working on implementing the home screen consisting of a list of the users posts using demo data, as well as reworking the overall design layout for the app. I’m planning on finishing up the base UI structure for the app with open hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. for the various backend functions.Once this is done, I will be moving on to the backend functions for retrieving and displaying actual user data.

DEVELOPMENT ROADMAP
—————————————–

As per development schedule I started with the Compose module last week and have moved up to the other base modules this week, which means, that I’m almost back to the schedule as per the initial plan, with only one deviation. I’m primarily concentrating on getting the skeleton for the app ready by the end of this month or start of the next month. Once, the base skeleton is ready, implementing the newer functions should be a pretty simple and straightforward job.

#firefoxos