migrate mobile app to RL enabled mobiile app

Corey Osman's Avatar

Corey Osman

02 Jan, 2012 10:40 PM

I have an app: http://www.remoteadmin.co. Its about 8 months old and was my first real world experience writing a mobile app so there are plenty of mistakes. I started to notice as I added features that my code was difficult to understand as I didn't have a framework. Anyways, I would like to fix this problem and rewrite my app to utilize the RL framework. My questions is:

Can I slowly introduce RL into my app (migrate) and still rely on older code or do I need to start from scratch. I would really like to go through each view and change to use RL. Right now I have a library that acts as my services lib and communicates to my REST service as well as the mobile application project.

What is the best approach?

  1. Support Staff 1 Posted by Ondina D.F. on 03 Jan, 2012 06:04 PM

    Ondina D.F.'s Avatar

    Hi Corey,
    The short answer is, you can ‘go through each view and change to use RL’,

    • if you built the Views using a modular approach, meaning they could run separately without problems as if they were a separate application

    • if you don’t have business logic and domain logic in your Views

    • if your Service classes are reusable and well encapsulated

    • if you can easily identify and separate the domain logic from the rest of your app

    • if you can provide the Service classes with an eventDispatcher

    • if you can easily mock a service call

    You can even create a Context for each View/functional area, if you wanted to.

    Anyway, it doesn’t matter which framework you’d use and which patterns you’d apply, the first thing to do would be to identify the tiers and layers of your application and to separate the logic pertaining to each tier. I’d start with the Services, Models and Views, because they are the parts that should be reusable, more or less.
    I have identified about 6 main functional areas in your application: Home, Hosts, Reports, Facts, Groups, Info (from the screenshots). Interesting application, btw.
    So, start with Home and build it as a separate app using robotlegs. See if it has any dependencies on other Views or other parts of your app, and make HomeMediator responsible for the communication with them.

    If you need a more detailed answer, you’ll have to give us more details about what you want to achieve or the issues you’re encountering :)

    Ondina

  2. 2 Posted by Corey Osman on 03 Jan, 2012 06:59 PM

    Corey Osman's Avatar

    Well I do have my code separated as much as I can. Here is what I have thus for (pre RL)

    -- remoteadminlib

     --- controllers
     --- models
     --- services
    

    -- remoteadmin mobile app -- remoteadmindesktop app

    The remoteadminlib is essentially my services layer. It holds the models, controllers, and some other reusable business logic or custom components that the mobile and desktop app use.

    The views for the most part only interact with the controller, where as the controller only interacts with the services and models. I use events from the controller to notify the view as each controller extends EventDispatcher. The controllers usually have lots of code to reshape the data or send an event out. The views usually call some controller method to get data and then listen for the response from the controller that has the data so they are decoupled in a way.

    The views seem to have more AS code that I would prefer. My hopes with RL are to remove most of this code and put either in commands, services, or the mediator. Currently I have all the logic to write to disk in my view which I would like to move to a service.

    One interesting difference when comparing how DI works and what I use now is that currently my app holds all the controller instances in memory via a Dictionary Hash. The instances are created on first use and then stored. However, my code has snippets of this controller creation in every view which is kinda messy. My controllers even have this same code to ensure the other controllers exist. Many of my controllers have to communicate with each other which could be a big difference with RL.

    Here is an example of code that would go away with RL. Probably 1000 lines worth throughout the app since I have to ensure that controllers exist before using. Ahhh, I can't wait to get rid of this code.

    http://pastebin.com/95i8Wva5

    Two questions I have thus far are the following:

    1. Is the mediator only able to talk to the the specific view it was created for? Can I inject anything else besides models?
    2. Whats the best way of pushing views on the stack along with the data? Is the Mediator the only way or can I use a command? (I acutally tried command but couldn't Inject the view so I could not use the below statement)
      view.navigator.pushview(NextView, data)
  3. Support Staff 3 Posted by Ondina D.F. on 04 Jan, 2012 04:18 PM

    Ondina D.F.'s Avatar

    Two questions I have thus far are the following:

    1. Is the mediator only able to talk to the the specific view it was created for? Can I inject anything else besides models?

    Actually, I would say that Mediators don’t “talk”, they “shout” - dispatching events, on the shared EventDispatcher provided by the framework, to which interested actors, like Commands and other Mediators, will then react.
    Many analogies have been used to describe the role of Mediators: a bridge between the View Components and the rest of the application, a mailman, a switchboard, a secretary, a waiter...
    In other words, the Views (Components) should be completely unaware of the framework and should encapsulate the code specific for displaying data, user interaction, layout, design. As already mentioned, no business or domain logic.
    The Mediator is a two ways communication channel:

    • from the View to the rest of the application by dispatching events ( announcing changes due to user interactions or the need for some data to be displayed)

    • and from other parts of the application to the View by listening to events and accessing API methods on the View (data to be displayed or actions to be performed)

    So Mediators just listen for events, dispatch events and access methods in their Views, letting the Views handle and manipulate the data.

    If you want to strictly follow the recommended practice you should avoid having business or domain logic in your Mediators. Also avoid using the Mediator as a View Controller or code behind class. In this light, you should only inject into a Mediator the mediated View, the events (or Signals) needed for the communication with the rest of your app, and maybe VOs that you’d want to pass to the view.

    Of course you can inject a Model or even a Service into your Mediator, if you want to, but make sure that you first understand the implications of such an approach! Try to understand the Best Practices and to follow them as much as you can in the beginning. The moment you are comfortable enough with the framework, you can easily take the approach that’s best suited for your needs.

    Injecting other Mediators or accessing their methods is something you really shouldn’t do!
    If you want a Mediator (or any other actor) to communicate with other Mediators let it do it via custom events. Mediators are good listeners ;-)

    2.Whats the best way of pushing views on the stack along with the data? Is the Mediator the only way or can I use a command? (I acutally tried command but couldn't Inject the view so I could not use the below statement) view.navigator.pushview(NextView, data)

    The best way, in my opinion, is to let the View (Navigator) push the views on the stack. The Command should just dispatch an event with a payload containing the info needed by the Navigator. The Mediator, listening for that event, would pick up the data and pass it to the View. For example:
    In the Mediator
    protected function changeActiveView(event:NavigationEvent):void
    {

    view.changeActiveView(event.viewClass);
    }

    In the View
    public function changeActiveView(viewClass:Class):void
    {

    navigator.pushView(viewClass);
    }

  4. 4 Posted by corey on 04 Jan, 2012 07:14 PM

    corey's Avatar

    Thanks this helps. I have spent a lot of time this week already creating RL version on my app. I see the light now and understand whats going on.

  5. corey closed this discussion on 04 Jan, 2012 07:14 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac