Migrate from web-based to native with Shinobi

[juan294]

Hi guys, 

I'm planning to do a migration of my reporting app from HTML5+JS (Fusion Charts) to native (Shinobi) and I have a few questions in which I'd like to have your feedback if possible:

1) Working with JSON | WS:

Since I've been a web developer for a long time, working with web services and JSON on web apps is something I can picture in my head clearly.  Making the move to iOS Objective-C and native apps introduces a few questions in my general migration plan.  

I know since version 5 we have native JSON handling within iOS and I was wondering if there is any special consideration I need to take into account when working with external data sources (WS and JSON).

I checked all tutorials and guides but I didn't see any example of external/remote data sources feeding the charts.  Any thought on this?

2) Drilling down (second level charts):

Something else that’s essential in my app is second level, (or detailed) charts.

I usually go on my reporting app from the general to the specific data.  Maybe showing a simple Pie:

and allowing the user to touch a section and then query my DB again, rendering a new chart (Lines, Bars, etc) with the results from that query:

I’ve notice that on the ShinobiPlay app, on the “touch” section (Names for pet turtles after 1984) you can detect the touch of a section and trigger an animation. 

Is this behavior reserved for the animation or can it be also used for a view transition too? Can I use this to make my second level query and bring a new detailed chart? Is it the recommended (proper) way to accomplish this?

3) Real time: **** 

The last important thing on my mind regarding the migration of my app is the real time monitoring feature.

I’ve checked apps like Server Density and I know the use Shinobi charts and put their API in charge of feeding real time info to the iPad app.

I’m a bit lost here when thinking of implementation since I’ve been using specific real-time widgets provided for Fusion Charts to retrieve this information from my JSON files.  I’m worried about network load and resources demand in general, especially in older iPad models.

Any thought, ideas or suggestions provided by your experience would be greatly appreciated.

What I’d love to have from you is not specific code to solve my problems but ideas on how to tackle this important features using these incredible libraries so I can continue to design my migration. 

Any feedback is more than welcome.

Thanks in advanced for your time and help.

[Colin_E]

Hi Juan,

Glad to hear you are looking to migrate away from Fusion Charts. I am guessing you are the same Juan I had a few emails from earlier this year? Since then we have had a major visual refresh. I'm happy to say that there is more to come - we have some more dynamic effects / animations in the pipeline.

Anyhow, onto your questions ...

1) JSON / WS - There are no special considerations you need to make here, feeding data into the chart from JSON obtained via the web is a very standard scenario, and with  NSJSONSerialization this is really easy to do. I don't have any examples to hand, probably the closest is from a recent MonoTouch blog post  which demonstrates the parsing of CSV data which is then fed into the chart. I'd suggest that you just give it a go, and if you get stuck, give us a shout on this forum.

2) Drilling down (second level charts) - the chart can notify your code of user interactions via the SChartDelegate protocol. If you adopt this protocol and implement the  toggledSelectionForRadialPoint method you can receive notifications when the user taps on pieces in the pie. This should allow you to implement a drill-down effect.

3) Real time - currently the data is supplied to the chart via the SChartDataSource protocol. If your data changes, then you need to inform the chart that data has changed, you do this via the reloadData method on the chart. If you are familiar with  UITableView this should all make sense as it is the same pattern.

In order to make recommendations about how you might use this approach, I would need to know a bit more about your real-time data, and how it changes over time. However, ShinobiCharts are really fast - so should be able to accomodate any reasonable real-time needs.

If you want to describe your real-time charting needs in a bit more detail, I'd be happy to provide some more guidance.

Colin E.

[juan294]

Hi Colin!

Yes I'm the same guy.  I think is time for me to give ShinobiControls a real try and make a native demo of my reporting app.

I know you've been working hard on visual aspects.  In fact, a huge part of my decision to migrate is based on the fact that I know you're working to make it better as we speak (write).  Chart animations and UI perks (shadows, vivid colors, themes, etc) are so important to this that I can't even fully explain it (even though you know I've tried and even though I know you know it).

Now I want to master your libraries and try to accomplish everything I have on my current app with the advantages of smoking fast ShinobiControls

What you explained is exactly the kind of guidance I was looking for.  I'm going to have this next week almost exclusively for working on this and even I have done some of the tutorials back when you started, I want to go through all of them again.  Refresh the basics and get confident before starting the implementation along the week.  I'll be probably back here with some questions (I love that you have this forum now!)

I'm going to meet with a friend who's working with me on the backend of the project and discuss a bit more about the real time needs.  So far this is all a project we're making to offer to partners and potentials clients so we don't have fixed requirements or demands.  We're trying to do something that is as appealing as customizable.  A product that can be adapted to different scenarios and clients.

Thanks for all you help.  It's a luxury to have this feedback. I'll be back for sure.

Juan.