CiviMobile: Where we go from here...

Thank you for blogging on! Check out the blog policy for more tips on how to better engage with the community.
2011-12-10 08:40
Written by
Anonymous (not verified) - member of the CiviCRM community - view blog guidelines

The CiviMobile web app is now underway and being developed with the jQuery Mobile framework (HTML 5). 

The app is Based on the prototype that Xavier and Kyle created, and is beginning to take shape, the functionality in place at the moment includes contact/activity search, add contact and view list of events.  It’s intended to be used by an organisation’s staff, as a tool for them to use on the move.

During the EU code sprint next week my focus will be on getting phase 1 completed and giving a demo to some potential funders.  Checkout the wiki for the full spec.  Once its ready I will be looking for some volunteers in the London area who'd like to do some user testing at my university within their interaction lab, which involves cool eye-tracking equipment! 

We are also going to use phase 2 of development to test out a new PHP framework: Symfony, with a view of potentially using it as the main framework for Civi.  Phase 2 will include an event check-in tool, survey capabilities for use with CiviPetition and CiviCampaign, as well as some other GPS-based features such as contacts near my location.

Phase 3 of the app takes on a new perspective in the way that people interact with CiviCRM.   It will allow users to record information offline and then upload any data collected to Civi, once an internet connection becomes available.  The use case for this is from a funder who is looking to use Civi in third-world countries such as Africa.

If you're interested in taking a look a progress so far you can visit and login with demo demo.




the mobile app can (and should IMO) be almost only static html and js contains all the logic. All the data fetching/update should be only using the ajax API. Under these, not sure what's the benefit of trying a new framework on the server.


(we didn't follow that road all the way partly because one of the goal of civimobile was to demo the php api)



I have very mixed feelings about the idea of using Symfony...


a) I mostly agree with Xavier -- a new mobile web app should use the current API. (And where there are missing entities or actions, they should be addressed by improving the API.) Bringing in another PHP framework doesn't seem necessary, and it's likely to introduce more issues/distractions during implementation.


b) The main justification seems to be grounded more in the politics of getting the community to move on to a nicer application framework -- i.e. this provides an excuse to introduce Symfony. It's a worthy goal and a clever play. "CiviMobile" is compelling enough that it might get attention/interest, and it's distinct enough that it won't screw up the entire system. But it's also risky -- if Symfony fails to get traction in the Civi community, then the CiviMobile codebase is much more likely to bit-rot.


c) If offline operation is a serious goal, then it will introduce a series of requirements/mechanisms that we don't currently address in the $.crmAPI approach (such as on-device data-management and data-synchronization). If Symfony has already tackled these issues, then using/integrating it might be a good idea.


1. i think the mobile app will be a combination of the php + html5 + js. Over a period of time we'll be adding config information in the DB to decide what fields / data to expose in the mobile app (similar to how SF and Sugar do it). I dont think it will be static html + js only. We'll make a strong effort to use api v3 for all/most of it


2. I think we need to take a stab at it and experiment with potential solutions. We've been talking about it for a long time and its good for some of us to play around with something out there and get a few more ideas. This also makes us appreciate a fair bit of what we have already built. In the worst case its a throw away experiment and we learn something from it, in the best case we start a migration of the platform.


3. I have no idea how to even think about doing offline in a reasonable and sane way. There is offline on a labtop (where u could potentially conceive of a local intranet running mysql et al) and there is offline on the phone.



1. Isn't the "what fields to expose" similar in goal to what profile does already? (and API3 is probably almost complete enough to be able to fetch the list of fields in a profile).


2. For what i've quickly seen, symphony seems like a nice framework indeed. Something that would be useful at large and needed as well for civimobile is a templating engine that works on the client. Seems to have several interesting as well. Comments welcome


3. html5 offers offline storage already that could be leveraged for simple things. The issue no matter what is going to be the sync/update. The only "simple" solution I'm aware of is using couch.db could be an option to add offline features to civimobile, by syncing the contacts to the existing native address book.