06-30-2012 01:10 PM
It's all about the content! My post is regarding web services.
URLRequest is great. But let's say I have my own web service. Let's say you want to make calls to an API. I make a call to it like so:
This spits out JSON and I need to do something interesting with the data. How do you handle multiple calls. Whats best practice. What about screen management? In terms of file structure, how do you connect all the classes together?
Do any of you have open-sourced code you can share?
I imagine this can be helpful to anyone using APIs or their own web service.
06-30-2012 09:56 PM
Building an app that communicates with a web service using JSON is basically no different than building apps that communicate with local datstores. There is a lot of information on the web for building UIs and managing screenflow. Google is your friend.
You will probably want to construct a class that encapsulate the code required to handle the two-way encoding/decoding of JSON strings. By using standard object oriented techniques, you won't have to write the same code over and over again. If your class extends EventDispatcher, you can even dispatch custom events to handlers in your UI components. There are many places on the web that will help you leverage the AS3 event model to your advantage. Again use Google to find generic examples that you can adapt to your JSON requirements.
For specific informaation about how to encode and decode JSON strings and how to send and receive data from your web service, you might start with the following tutorial. If you need more information, did I mention thet Google is a useful tool for this purpose?
07-01-2012 09:17 PM
That is a useful link thank you. Google has not been my friend in finding a good overview of how things fit together. If you don't know what terms to search then it can really take up a lot of time. At the end of the day, you're still stuck with headscratching on how actually a production level application can be made.
Here are a few links I found also that are very helpful:
My question is,
How do you structure the calls to the web service to make it so that it's not pinging your server every time someone presses a button in your app?
How do you structure your files, and classes as to make them re-usable for other applications that require making HTTP calls?
Need a good explanation from someone who is doing this in their app. If you are, can you contribute your thoughts/code/maybe a tutorial to the community?
07-03-2012 01:37 AM
You are not finding Google answers to you questions because they are not really about "web services" at all, rather they are general questions about best practices for building data-aware client-server apps of any kind). To illustrate, let me change the woirding of your questions to something that a devedloper unfamilar with SQL might ask.
"How do you structure the calls to a database to make it so that it's not pinging your database engine every time someone presses a button in your app?"
"How do you structure your files, and classes as to make them re-usable for other applications that require making database calls?"
It's not that I don't want to help but your questions are outside the scope of a forum dedicated to the RIM SDK for Adobe Air. I only rsponded becaue nobody else responded to your post and I did not want you to think that we wern't being nice. Regardless, I am going to do my best to answer your questions even though they are not really on topic.
As a rule of thumb, the UI of an app that uses a database server will look identical to an app that uses web-sourced data. It will present app-specific forms so that user scan specify what they want done and there will be well-placed buttons to submit the forms to the service. This answers your ffirst question, now on to the second.
The wrong way to build an app is to include app-specific code in your Ui components that sends requests directly to the backend and receives results directly from the service.Your UI would get very messy because you would be copying and pasting handlers in each and ever one of your forms. If you change your backend service, you would have to re-write your UI. Instead of creating spaghetti, you should construct generic (reusible) handlers.that sit between your UI and the backend. The flow looks like the following:
When a button is clicked, your app's data-handling component marshals the form-data into whatever protocol (format) is demanded by your service (SQL statements for a db server and XML/JSON for a webservice). Your handler would then send the request to the sevice and wait for a response. When your handler has received a response from the service, an event will be dispached back to your UI so that the data can be handled by app-specific code.. Just make sure that you use a gerneric custom protocol (be it JSON, XML, or an AS3 array/object or whatever) to pass information to and from your middle-ware and you will be off to the races
You are well on your way to building your reusable "middle-ware" data handlers for a web service. Just follow the advice given in the urls that you posted. And just for the fun of it you should wite a different set of handlers to communicate with a SQLdatabase server. If it's done right, your will not have to change a kine of code in your UI. You will just need to uplug one data-handler and replace it with another.