This post is a synthesis of two posts I originally published on my other blog "unRelated".

One of the key foundations and most attractive principle of Agile or Lean methodologies is that  "Everyone can help each other remain focused on the highest possible business value per unit of time".

I am certainly a strong supporter of that principle. However, value is often difficult to assess, I would actually argue that it is easier to identify what has less or little value, but what we think as valuable can potentially lead to many false positive, or simply be "business-as-usual" and hide the broader structure of the solution. 

"User Stories" are the corner stone of identifying and delivering value:

An argument can be made that the user story is the most important artifact in agile development, because it is the container that primarily carries the value stream to the user, and agile development is all about rapid value delivery.

In practice, very few people focus on the benefits part of a user story. All user stories I see are either what we used to call "requirements" (just phrased slightly differently but isomorphically) or "tasks" needed to advance the state of the project.

However, there is a fundamental flaw in the construction of user stories, even when they are properly written, because they somehow make an assumption about the shape of the solution, and drive the author to turn almost immediately in solution mode, leaving no room for creative and out-of-the-box thinking.

Let's compare the metamodel of a User Story and to the formal definition of a Problem. The metamodel of a User Story looks like that (using the BOLT notation):

As a <role> I want to <action> so that <benefit>

us-model

I define a problem formally as a non existing transition between two known states [1],  the metamodel of a problem looks like that:

pb-model2

 

A solution is a way to transition between these two states. Please note that both the actors and the actions are part of the solution:

sol-model

 

This is where the problem lies when using User Stories, you are specifying the requirements with the solution in mind. There is, of course, a general relationship between some of the actors and entities of the system with the "start" and "end" states of the problem. The problem states are always defined in terms of their respective states (possibly as a composite state), but it is a mistake to think that the actors and entities that perform the actions, as part of the solution, are always the same as the actors and entities related to the (problem) states.

Hence, an action is solution centric and should not be part of the problem definition. As soon as you pick one, you have put a stake in the ground towards the direction you are going to take to solve the underlying problem. The other issue is that the start and end states are never clearly identified in a user story leading to confusion in the in the solutioning and verification process, since the problem is not defined with enough precision. Benefits could sometimes align with the target/desirable state, but the definition is often too fluffy and more goal centric, not effectively representing that (problem) state.

Ultimately, the relationship between problems and solutions is a graph (states, transitions as problems, actions as solutions), and this is where the coupling between the problem space and the solution space at the User Story level becomes unfortunate. This means that User stories cannot be effectively nested and clearly cannot fit in hierarchical structures (which is common to most Agile tools I know). This problem is quite accute as teams struggle to connect business level user stories and system level or solution level user stories. The concept of having a single parent directly conflicts with the possibility of having multiple possible transitions into a single state and decomposition principles where the same problem appears in the decomposition of several higher level problems. 

I feel that distinction is profound because we can now clearly articulate:

a) the problem statements with respect to each other (as a graph of states and transitions)

b) we can articulate the solution in relation to the problem statements

c) we can articulate the verification (BDD) in relation to the problem and solution [2]

d) we can actually articulate the Business Strategy [3], the Problem Statement, the Solution and the Verification with the same conceptual framework

e) derive the Organizational IQ from the problems being solved on an every day basis

To the best of my knowledge none of these articulations have been suggested before and no one has ever provided a unified framework that spans such a broad conceptual view from the Business Strategy to the Verification. In the proposed framework the business strategy is simply a higher level and specialized view of the problem and solution domains, but using the exact same semantics (which are described here). In other words the enterprise is a solution to a problem, which is a composition of smaller problems and more fine grained solutions, etc. This has an extremely important implication for the execution of the strategy because now both the Strategy and its Execution are perfectly aligned, at the semantic level: the strategy, problem, solution and verification graph represent a map that everyone in the organization can refer to. 

To take advantage of this new conceptual framework. I suggest that we make a very simple and easy change to Agile and replace "user stories" by "problem statements". Each problem must be "solutioned", either by decomposing it into simpler problems or solutioning it directly. Value can still be used to prioritize which problems are addressed first, that part of the Agile and Lean movement is very valuable, so too speak, but the focus on problems and solutions opens a new flexibility in how we handle the long range aspects of the solution while enabling the highest level of creativity and ultimately a direct articulation with the IQ of the organization. 

As problems are decomposed, we will eventually reach a point where the subproblems will be close to or isomorphically related to the solution. But it would be a mistake to not clearly delineate the problems from solutions, simply because at the lowest level, they appear isomorphic. 

If we start drawing some BOLT diagrams, a problem lifecycle can be defined as:
problem-lc

The fact that the lifecycle is pretty much identical as the one of a user story enables most of the Agile processes and tools to work nearly unchanged.

You may want to know "How do I write a Problem Statement?". Personally, I don't like canned approaches. Oviously here, the mere definition of the two states (low value and high value) is enough to describe the problem. If a solution already exists (i.e. it is possible to transition between these two states) you may want to describe some characteristics of the new solution. I googled "How to write a Problem Statement?" and I felt there was already a good alignment betweent the results and the abstract definition provided above. For instance:

We want all of our software releases to go to production seamlessly, without defects, where everyone is aware and informed of the outcomes and status. (Vision)

Today we have too many release failures that result in too many rollback failures. If we ignore this problem; resources will need to increase to handle the cascading problems, and we may miss critical customer deadlines which could result in lost revenue, SLA penalties, lost business, and further damage to our quality reputation. (Issue Statement)

Here we see two states for the releases: initial state (low value) tested, and the high value state (in production). There is also an undesirable state (failure) that the new solution will prevent reaching. For me the most important thing is that the problem statement must avoid at all cost to refer to the solution. Even if the people specifying the problem statement have an idea about the solution, they should capture it separately.

This new focus on problem & solution provides a rich conceptual framework to effectively organize the work of a team. After all, we have been innovating, i.e. creating solutions to problems, for thousands of years, so it is no surprise that our vocabulary is quite rich. Here are a few concepts that could be used:

Goal: a goal is not a problem, but you often need to solve problems to reach goals, so it's important to keep them in mind

Fact: a fact often constrains the solution, so they need to be clearly surfaced and accounted for

Assumption: assumptions are very important because they also constrain the solution, but in a more flexible way. Assumptions can be changed, facts generally cannot.

Statement: the problem statement is what physically replaces the user story.

Hurdle: During the decomposition of a problem, hurdles might be identified, they are not a problem per say, but they impact the solution. It could be for instance that a resource is not available in time to meet the deadline.

Snag: A problem can be downgraded to a snag as the solution is obvious to the team and represent a low level of effort. It can also be a small unexpected issue, that need to be quickly resolved.

Dilemma: A problem can be upgraded to a dilemma, when several solutions are possible and it is not clear which one to chose

Setback: The team can suffer a setback when it thought it had found the solution but it didn't, or could not find a solution and need to reassess either the problem or the approach

On the solution side, we can also capture different elements and stages of the solutioning process:

Answer: Findings related to a question raised in the problem statement.

Result: A validation that the solution conforms to a Fact

Resolution: The choice made after reaching a dilemma

Fix: a temporary solution to a problem or a snag to make progress towards the solution to the greater problem

Development: An element of the solution, usually the solution to a subproblem or a snag

Breakthrough: The solution found after reaching a setback

Way out: A solution was not found, nevertheless, the project reached a satisfactory state to meet some or all of the initial goals

...

From a management perspective. The Solution or Delivery Manager can escape the bureaucracy that Agile has created. Ironically, moving stickers around is a zero value activity, with zero impact on the organizational IQ. The solution manager can and should be responsible for the IQ of the project, which rolls up and benefits from the IQ of the organization. It should keep track of the elements that are incorporated in the solution as problems are solved. It should encourage team members to be creative when necessary and to shamelessly adopt existing solutions when it makes sense. It should help resolve dilemmas and push for breakthroughs.

The PMO organization becomes the steward of the Organization's IQ.

As we define problems and solutions in terms of entities, state, transitions and actions, the BOLT methodology provides a unified conceptual framework that spans from Business Strategy to Problem and Solution Domains to Verification (BDD).

To summarize,

1) We have provided a formal model of a problem and a solution, and how they relate to each other

2) This formal model offers the ability to compose problems and solutions at any scale, over the scope of the enterprise

3) Problems and Solutions can be composed from Business Strategy down to Verification

4) We suggest that Agile methodologies replace User Stories by Problem Statements

5) With the renewed focus on "problems", we can also integrate the work of Prof. Knott on Organizational IQ in the whole framework

Last, but not least, decoupling problem definition and solution yields a tremendous benefit in the sense that both can evolve independently during the construction process. 

_______________________________________________________________________________

[1] For instance, you build a vehicle, obviously you want to car to transition to the "in motion" state. Different "actions" will lead to the vehicle to reach that state (a horse pulling, an engine, transmission and wheels, a fan, ...).

[2] BDD Metamodel (Scenario):

bdd-model

 

[3] Living Social Business Strategy mapped using the same conceptual framework (Source: B = mc2)

lifecycle

jdubray
07/25/12

Mobile App Monetization

David Barnard wrote a really interesting post on the recent acquisition of Sparrow. This is a must read for any mobile developer expecting to make a living from their craft. This could actually very well be the best article written on the topic.

But I want to warn people against his conclusion. I think there are two elements of his rationale that are flawed.  He wrote back in 2009:

unrealistic pricing expectations [...] may haunt the entire mobile software industry for years to come

And added today:

In hindsight, I think “haunt” was the wrong word to use. Though it wouldn’t fit quite as well semantically, or be quite as provocative, I think the right word to use there is “change”.

The reality is that Apple successfully delivered a monetization platform, this is actually one of the most fundamental change introduced by mobility (with location). Not so much because developers can -now- potentially be free from the -bait- model the Web introduced where the end-user "is-the-product", but because now commerce can be delivered in a fundamentally different way. An app is just an agent of commerce not the object of commerce

The Web never ever changed how commerce was done. e-Commerce was commerce and is still commerce 20 years later, you still take this bit of plastic out of your wallet, and you still establish a one to many relationship between yourself and a bunch of people. Even in other areas such as outsourcing, the Web didn't change much, call centers existed before the Web, they simply moved. The Web just abstracted (a bit) location, but for all intend and purposes the Web didn't change a single thing to the way commerce was done.  It might have gave you the illusion, that's all.

What The Platform is changing fundamentally is that it introduces a mediator in the commerce relationship, a One-to-One-to-Many relationship, actually it is even more complex than that, it introduces a One(end-user)-to-Many(apps)-to-One(platform)-to-Many(merchants, service providers). It does that in a relatively secure and private way allowing financial transactions to flow between all these actors. 

Claiming that you can't make a living because a single business model (selling apps on the app store) doesn't seem to bring in enough income is at best short sighted. I can come up with at least 10 transaction models (exclusing ads which transformed the web into a zoo) that will help developers and service providers monetize their relationship to end-users.

Just this morning I stumbled upon this eBook that the French newspaper Le Monde just published. It was written on iBook Author, one of the most amazing "app" I have seen in a long time. And all the sudden everything became clear, this was the business model the press was waiting for: news has become a commodity, nobody wants to pay for news. Social network have forever disrupted the relationship between newspapers and their readers. But ... at roughly $5, lots of people might pay for the analysis behind the news, the broad perspective that the journalists can provide because they follow astutely "the news". And yes, in case you have not noticed, in a fairly incredible turn of events, turning the entire model of the press on its head, the "news" becomes the ad that would lead to customers buying the eBook. What better ad, than a piece of news that will drive people wanting to know more, wanting to understand deeper perspectives well beyond the news?

The second flaw in David's rational is the "one-size-fits-all" mentality of app developers. This is a major flaw, again inherited from a very old age, when you could not address a billion potential customers. This is what "The Platform" changes, unlike the Web, which at best allowed one person to buy stuff and services from a remote places, the platform turns the entire commerce model on its head. It allows anyone including David to sell into a one+ billion user market. Do you really think that "one app" can appeal to 1B users? Angry Birds, anyone? Isn't it time to rethink what software is? Don't you think that a) if you are lucky, one app would only resonate with a small subset of this billion users and b) if you are not, you may never find your market, when in reality a different set of features organized in a family of apps could have found many  "puddles" of 10-20 million users? Take any of David's apps, don't you see how they could be organized into a family of apps that could appeal to many different market segments, geographies, ... even price could be different. Some users might be paying $20 for a premium app, other would never pay more than $.99 for a couple of features, but maybe that's a 100 million puddle.

For the last 20 years our economy has been trained  to standardize products and to perform binary commerce transactions. I don't know the future, all I know is that people who will not think out of the box page and people who will not try to understand the tectonic shift introduced by the Platform will come to the wrong conclusions. In essence, the only thing these people are telling us, is that BAU (Business As Usual) is dead because it does not work on the platform. 

Of my entire career, nothing has been more dramatic and transformational than when Steve Jobs returned to Apple in 1997 and shelved NeXTStep. All my dreams, all I had worked for, for 10 years, were shelved as well. By then, companies like GM, Hughes, Samsung, NTT, Siemens, EADS (Aéropsatiale back then), Essilor, lots of research labs in Europe, ... were using my software doing great things with it and somehow, this was shattered in one instant. Believe me, when people complained they could not upgrade their Lumia 900 to Windows 8, they are not even 100 miles close to the pain you get when you see a full decade's worth of work go away as your technology platform vanishes before your eyes. To a certain degree I think we have all lived this kind of event, not as instant and comprehensive as the NeXTStep one. Even Flash gave a 5 year warning to its developers. 

With that in mind, I was amused to see this Mobile Development Platforms Gartner Quadrant this morning. A friend of mine asked me what did I think of it? What is a sensible no-bs lasting mobile strategy  in 2012? I didn't see the Web Platform Magic Quadrant CIRCA 1995, but I bet it was not much different. Tiny (NeXTStep-based) WebObjects was the leader then... how many iterations have we been through? who could have predicted the rise of PHP? where are we now? All we know is hype always got it wrong, despite all the might of a Gartner or an IBM or Microsoft, completely wrong. "What works" wins. Always. So here is my answer:

1. Create your picture of the device market

We are at the last stop before this market is completely locked in by Apple and Google. I wrote that piece a couple months ago explaining that unless Microsoft somehow associates itself strongly with Facebook, Nokia and HP and adopts a vertical strategy, there will be no Microsoft in the mobile space moving forward. Today we know for sure the device market will be at most a three platform game and, after watching Google I/O's Keynote, my bet is that it will be just two platforms. Anyone who is trying to convince you otherwise simply doesn't understand that a device that runs an app can no longer exist without a platform behind it. If Sony, RIM or even Amazon do not have a sustainable platform behind their devices, nobody will buy them. It's funny how people can't grasp the "form factor" of software: they see a device, they think this little thing is autonomous, doesn't rely on something other than a voice and data connection, they don't see the extend of the software component behind. If they somehow could visualize some of their systems with a physical representation, I bet our industry would look much different. For instance this is a picture of the Nokia Lumis 900 after Microsoft's annoucement last week and here is a "Kindle" for instance (albeit not as pretty, I mean the Kindle is not as pretty as this public bench):

2. Understand that writing software for mobile devices is unlike like writing software for desktop

I would recommend a couple of presentations:

a) 6 Design Rules to Design Amazing Apps

b) Building Mobile Applications That Rock

c) The mobile user experience

I would also recommend you understand where you fit and how you plan to use the mobile ecosystem. Here is a map that can help you:

3. Native vs Web?

Except for the people that make a living off Web technologies or the ones that are emotionally attached to the Web as a platform, everybody will tell you that HTML5 is not there yet and most likely will take at least a couple of years before it can catch up with native technologies, if ever. Just ask yourself how many Web apps do you actually use on your own smartphone? zero? Why don't you also ask, of all the native apps that you use, which one would be better as a "Web app"? zero? Users choose the best UX, period, technology is the least important factor in their choice. I mean come on, after nearly 20 years of evolution who can tell me that even on the desktop there is a Web app they would still use if they had a native choice? Everything that the Web was not, Apple baked it in its platform and won. Maybe the industry could stop for a second and ask why? If you still don't believe me, please watch this presentation. Even Facebook finally gave up ... 

Not only Mobile Web frameworks don't work well in all the devices browser (contrary what the vendors say...), but you'll still have to deal with pixel level precision across multiple device form factors, they don't do that, not even close. Do yourself a favor, try building a small sample app (3-5 views with an API call) in iOS, Android and jQuery mobile, and try to run it on 5 common devices and let's talk again. Just for fun, just embed a call to a mobile Web page within one of your WebView and compare the user experience with the corresponding native view. Yes, as Google pointed out in its keynote the human eye can detect up to 10 ms delays. Even a ping can't be done in 10 ms.

If you want to take advantage of all the latest device capabilities do you think native or Web technologies will give you the best access? If you want to save bandwidth, power and deliver the best user experience, which app will do that? Native or Web?

Do you have an Android device? What do you think of the Google Weather App? yes, when you ask for the forecast and you are redirected to a "mobile-optimized" web page that displays the weather forecast in your city. Do you think you want your users to go throught the same kind of experience? Yeah, I guess you get my point. 

Don't be fooled by Web developers who see the train coming (or going) and they are either going to be steamrolled by it, (or simply stay on the Web platform, so to speak).

So, with 2 platforms to support, it is actually fairly easy to build a mobile team that will be proficient in both. Beware of people scaring you with the wrong problems to buy their tools. The only problem you have, the only question you should answer is how do I deliver the best user experience in the context in which the app is used for the devices that my end users have. Everything else is a waste of time, because we are now in an End-User driven market, geeks no longer have the luxury to chose what is convenient to them. They hate it, this is the first time in history they lost control of their technology choices, but they are going to have to learn to live with it if they want to tap the 1+ billion user smartphone market. That's actually very refreshing. End-users expect certain patterns and behaviors, these patterns and behaviors are all native. One of them is actually quite interesting: End-Users expect to spend money to buy native apps... 

4. Middleware

You would think by now that most companies will have developped some kind of allergy to proprietary/closed middleware platforms (or at least an immunisation mechanism). It is already bad enough to be locked in Apple and Google, imagine being locked in a much smaller vendor who can disappear, change direction or be acquired any minute. Yep, that's the value proposition of companies like Rhomobile (now SAP) or Antenna: support all the platforms you don't need while you get locked in ours. Even IBM would have never thought of this ... wait actually they did. They bought WorkLight for 70 M.

Why don't you ask them how fast they are going to be following evolutions of Apple and Android SDKs and how low the common denominator  in supporting every platform is going to be?

5. Keep it Simple

In the light of this context:

  • Rapidly evolving technologies and devices
  • Quasi certain dominance of 2, likely, or 3 vendors at most
  • UX being the prime factor of the success of an app
  • Pixel level precision GUIs
  • The Platform beneath
  • Subpar Web technologies

If Instagram can teach us something (other than printing money) is that Content is now produced, delivered and consumed in a completely different way: in context. The browser is dead, long live HTTP. Everything is on the table to be reinvented. 

My recommendation is keep your strategy as simple as possible: write your apps for iOS and Android. This is not the end of the world, it is relatively easy to hire a small team of polyglot developers. You don't need no middleware for that. Before you know it you would have spent millions of dollars for capturing just a few % of the device market or supposedly empower your developers to write apps in ... two platforms. Who in their right mind would spend that kind of money? Where is the business case? Just buy an iPhone or an Android phone for your employees who use any other device. That will be much cheaper than any middleware or developing for additional platforms.

Gartner will always be Gartner, they make lots of money selling these Magic Quadrants to both ... the vendors and their "customers". So you have to decide whether you want to be scared by that picture or leap-frog it with a Simple (but far from simplistic) Mobile Strategy. Your call ...

Post Scriptum: Mobile Web Sites

Yes, mobile Web sites are not going away. And HTML5 is a good fit for them. But you have to think in terms of form factors: understand that "search" has become an "app", a family of apps. You search in context, Yelp, UrbanSpoon, Fandango... on a mobile device, you rarely search out of the blue or research some information for your homework or paper. You search for a purpose and there is a search app for every purpose you can think of. Search might even be considered just a feature, not even a family of apps. So think of your mobile Web site as being a way to publish information to a small search app that people use now and then and that app is called Google. Again, think in terms of form factors. The Web form factor in a mobile world is this tiny island of HTML rounded up by a -plain vanilla- contexless search app. So all you really need is a couple of "Web" pages so people can find you if they care to look. Make sure you provide a link to your native apps on these pages. That's all your users care about. The Web is emphatically tethered. Make no mistake about ot. 

jdubray
06/01/12

Mobile Diet Update

I reached another milestone today. I now lost 40 lbs in the last 6 months. I just got under the 200 lbs mark (90kg). The rate of weight loss has slowed down just a tiny bit, but that would be expected. I am expecting to lose another 20 lbs or so.

The graph below represents about one year worth of data. I must admit that I could never imgagine I would be at that weight today. This kind of thing looked impossible.

My blood pressure is back to nearly normal, away from levels considered dangerous.

I did some blood test and my cholesterol was down 50 %, yes 50%.

I cannot emphasize enough that if I can do it, anyone can do it. Losing weight is actually easy unlike what an industry would like you to beleive.

jdubray
05/31/12

Wireless in Seattle

We have recently remodeled our home and moved back at the beginning of May after about 5 months in temporary housing. The question was then: do we reconnect it to Comcast or not? We had already dropped Cable two years ago -for the better- using Apple TV with iTunes and Netflix as our main source of media, but could we ditch their broadband connection too?

I know that LTE is coming and there is a high probability that a lot of people will choose to become wireless when LTE takes off. Unfortunately we are about one or two years away before that starts happening. In the area the only choice for LTE is Verizon, but with a 10 Gb/month data plan, it was out of the question to use it for our main source of Internet access. The familly consummes on average 1-2 Gb per day. That kind of overage would be quite costly. So I chose ClearWire which offers an unlimited data plan. I understand that WiMax is no LTE, but after being a happy mobile modem customer for over 3 years, I decided to give it a shot. Comcast as a company has always been a nightmare to deal with and the idea of poking even one other utility hole in our new home was not apealing to me. So I got a fixed modem and upgraded my mobile modem to a hotspot with the hope that these two internet connections would be enough for a family of 4. With several tablets and smartphones, a hotspot seemed to be a logical choice too.

After about a month I can happily say that the family is ok with the choice. Sure, I am not going to hide that we can feel that we get on average a 4 Mbps connection (with a relatively poor signal at about 40-60%) and unfortunately the hotspot does not get any signal in our home so my plan to use both the fixed and hotspot modems is not working so far. I can't say that these numbers would work for anyone, but we can watch an HD iTunes movie without interruptions and that was my acceptance criteria. Netflix or YouTube work just fine, of course.

So our new house has no phone, Internet or cable connection. We are 100% wireless. The builder has tried to convince us that will hurt our ability to resell it but since that's not our plan anyways, we built "our" home, not just a home.

I would not be surprised if we are the first Wireless home in Bellevue (I literally mean "built without the wires" not just using wireless services). I would not have made this choice if LTE was not on the horizon. I know for sure that this is a viable decision moving forward.  It's kind of silly but I marvel pretty much every day that this is even possible, thinking about all the technology that was needed to make it happen. I also enjoy the peace of watching media that we choose, without commercials. We only turn the TV on because we want to watch something. Even though that choice doesn't come cheap, I feel it is priceless in all the time the family gets back.

Here are the economics of our wireless home:

  • ClearWire Internet access: $100 / month for a fixed and hotspot unlimited connection, (the hotspot is awesome compared to my old mobile modem when I use it outside our home)
  • AT&T wireless: $200 / month for 3 iPhones and one Android phone  (yes, we call or text each other in our home, in case you wonder, of course, that's when the Galaxy SII doesn't run out of power -I must admit that Samsung has redefined the word "wireless")
  • iTunes and Netflix bills: about $50-60 per month

 

 

jdubray
04/22/12

Data is (Mostly) Flat

Canappi's Data Binding Framwork allows you get  data from a Web API and effortlessly bind it to your UI.

For instance, getting a Twitter feed and binding it to a table is as simple as that.

The core of the Canappi's binding framework relies on a simple assumption: Good Data is simple to bind. You shoudn't need a complex set of metadata,let alone a query language, to describe what you want to do. With Canappi, we reify data formats to a simple set of rows to keep the data binding definition (almost) always simple.

In XML, we often run into formats is something like that:

<collection>
<someOtherElement>...</someOtherElement>
  <row attr1="value1" attr2="value2"> <key3>value3</value> ... </row>
<row>
...
</row>
</collection>

The data binding definition is generally achieved with a couple of values:  the collection element (since it could be arbitrarily nested) and the row element.The algorithm can go arbitrarily deep to find them. Of course, we reify elements and attributes in a single dictionary for each row. In the case of the twitter feed we don't even specify the collection and the row elements since the feed is well formed and follows already the /collection/row format.

Things are a bit more complex with JSON. I found it a bit harder to identify where the "array" of rows is. Here is my reification algorithm. First, I identify where the rows are, then I flatten any subdictionary (and I ignore for the most part subarrays):

 

You know what? the life of the json data binder would be a lot simpler if API designers would also support a "mobile friendly" format. In JSON it could look like:

{
    "collection": [
        {
            "row": {
                "key1": "value1",
                "key2": "value2"
                ...
            }
        },
        {
            "row": {
                "key1": "value1",
                "key2": "value2"
            }
        },
        ...
    ]
}

What's the point of arbitrarily nested data structures (in a mobile world) ?

So here is the implementation of our algorithm, you can dowload an adaptation of the SBJSONParser on Github.

This is how you use it:

    url = [NSURL URLWithString:endpoint];

    ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
    request.requestMethod = @"GET" ; 
	
    [request startSynchronous];
	
    NSString *response = [request responseString];
	
    // Canappi tests for JSONP and removes it first
    // See generated code
 
id data = nil; SBJsonParser *parser = [[SBJsonParser alloc] init]; //Get a JSON object id parsedData = [parser objectWithString:response error:nil] ;
 
//First find the array, then flatten the rows, to get an array or simple key/value pairs dictionaries data = [parser flatten:[parser findArrayForElement:@"collection" andRow:@"row" wrapped:NO in:parsedData] forElement:nil] ;

Canappi also provides the ability to "join" two API calls and simply merge both set of rows in the same data structure.

 This post is a plea for API designers: Please give mobile developers the data structures they need to simplify the data binding process. There is simply no value in doing otherwise, just incidental complexity.

<< 1 2 3 4 5 6 7 8 9 10 11 12 ... 22 >>

Search

 Subscribe







blog engine