I am writing a Flex project in which I need to communicate with Paypal via their APIs.
Really not sure how to start with - this is my first flex/air application.
I won't be using any server side technology (no Java, Php, .NET, Coldfusion) - all of the requests have to come from Flex and the response be sent back directly to the flex application.
Can someone please give me an example or something to start with. Let's say implementation of RefundTransaction API
in Flex.
Is it possible? If not, then what layer do I need to add to the technology stack?
Just need some pointers and I will pick it up from there.
Thanks
Definitely check out this article http://www.adobe.com/devnet/flex/articles/flex_paypal.html
Essentially will need to figure this out myself as well. One of the BIG, BIG, BIG (big enough for ya) keys is to NOT include your API key anywhere in the application (or other sensitive info). This is one of the pitfalls with using a JIT language because it's based on a VM it can't be hidden very effectively.
Related
I'm writing a web app in Scala using the Play framework. I'd like to be able to push some binary data to my web server from another machine I'm using to do number crunching. I'd like to do this over http. Can anyone suggest the best way to do each side? Ideas that have occurred to me so far are:
Send the data up as a file upload via the usual play form processing. Nice on the (web) server side, but I'm not sure what libraries to use for pushing the data up from the (number crunching) client. In C/C++ I'd consider using Curl.
Send the data up as raw POST with the binary attached and encoded appropriately. Not sure how to do either side.
I've done each of the above on several occasions in Python and C++ (although not recently enough to remember how!), but am not a web dev (but a more general sw engineer) and have only ever had control of one side before - so have no idea what the best way to do this is.
Any thoughts appreciated.
Alex
It depends what platform (and language) you're already using for the number-crunching client part. If that 'client' is also using the Play framework (or at least has access to the libraries), then there are some very helpful tools for accessing web services; (see here also).
I realize that this question can start a discussion but that's really not my intention. We've created a Flex Application to take tests from candidates. The advantage of the Flex Application is that all state can be stored in the application running in the browser of the client. Things like time limits, navigation, scoring, ... can all be handled within the application without us having to worry about a back button for instance. Even running the app offline with Adobe Air isn't that hard.
My question now is if such an application could easily be made with HTML, Javascript, Ajax, ... ? The reason I'm asking is because an application in HTML would be much easier to distribute on Mobile devices for instance. Also, our domain model for instance is mostly implemented in AS3 (Flex) so using it along the server side means porting it to C#.NET. (with two codebases as a result).
Look at any good MVC toolkit, you will easily be able to handle this. Castle project is good as is Microsoft MVC, both of which allow you to choose from a variety of view engines to handle the actual page rendering thereby allowing you to choose the most 'mobile efficient' engine...
As for the technicalities, you would store all persistent data in a server session object.
I am working on a website and this website contains games and this games will need to submit score to the website so the website will handle saving the user game score in the database.
So i am asking about the standards and common techniques to do this communications between the website and the flash games, is it better to let the flash files call javascript functions or call server side code? i have no idea how this can be done
Note: i can ask the flash games creator to edit the flash files to call some functions.
Also may be 'not sure yet' i will need to send from the server to the flash some variables.
It would be better for you if you create some javascript api that the game creators can hook into. Then it is entirely up to you what you do with it: ajax calls to webservices springs to mind.
This would protect you from having to learn Flex or Action script and if you can get the agreement of the game developers on the api, then you have abstracted this interface and your implementation in the browser will be de-coupled from what happens in Flash.
Well, the way I'm used to it, is that firstly, you design an API for the service the game developers should use. Obviously, you have to actually implement the service. :)
The next step is to provide an SDK, that further encapsulates the API and makes working with it easy, bridging the semantic gap between the API and the client, and sparing the developers the dull work of marshalling calls and parsing return values.
You can provide the SDK for use as a runtime shared library, so that you can provide bug-fixes and other interal changes without requiring recompiles and updates.
The reason, why I cannot really agree with Daniel is, that I don't really see a benefit in introducing an intermediary layer. It is just one more source of errors and security issues. From my experience, the most dramatical changes I know to APIs is deprecation of calls, change of call signatures or structure of returned data. Since you're writing this from scratch, it is very likely to happen.
In conclusion, the best practices for me are:
a well designed API
documentation
an SDK
developer support
greetz
back2dos
I am considering creating a website with the complexity of Facebook that should be able to scale into the millions of users. My question is: Is there any reason not to use Adobe Flex for such large project apart from the obvious point of requiring everyone to have Flash installed and not having to rely on Adobe? In my view Adobe Flex would reduce the server load for Facebook, because more of the work could me done on the client side. Do you agree?
Of course Facebook could have been implemented in Flash. But then the question is would it have succeeded? There are reasons big web companies like Google, Facebook and Yahoo only use Flash as sparingly as possible.
The thing I would fear most is alienating users. The Flash plugin isn't the best piece of software out there. It is slow and likely to crash once in a while. If your app gets bigger you might get some loading times that might not be acceptable to your users. Also in my opinion full Flash sites just don't feel right because they behave differently from HTML websites. All great websites like Google, Flickr, Stackoverflow or Facebook feel very light and slick which is very elegant makes up for great usability.
And then HTML and JavaScript are a lot more flexible. Do you want your website to be available on smartphonse? The iPhone has no Flash and even with phones that do you have the problem that users will very likely hate a full Flash site since those phones don't necessarily scale Flash as nicely as they scale HTML and Flash draws battery like crazy. If someone comes up with another revolution like smartphones you can be sure it supports HTML and JavaScript but you can't be so sure about Flash.
Then the question is how would you gain any efficiency? Of course you can write your UI with Flex and just call very lightweight webservices like you would use them for AJAX and you can even cache some of the content of the site locally so that you don't transmit more data as necessary for user interaction (the UI is transmitted only once). But you can also do that with JavaScript. You can write your UI in HTML and JavaScript, load it once and then just pull the naked JSON data from the servers and render it using JavaScript. You can also fetch lots of this data in advance to get the number of requests down. But still such an approach has its cons. Did you ever notice that when you type an answer on stackoverflow and someone else submits an answer you get notified while typing your answer. Such real time features are very cool and you might want this at some point in time which means more server interaction.
But whatever you do your servers still have to scale if your site grows. Even if you minimize the number of GET requests that hit your servers they will still grow a lot when your site gets popular and you will need a lot of servers to handle you will just improve your users/servers ratio.
The most interesting point though is that Flex is much easier to program than AJAX (think about browser incompatibilities for instance) and still AJAX was not only invented but the whole world messes with all those problems that come with it instead of using Flex. I think this tells a lot about of the value of the result you get when creating a full website in Flash.
Go to facebook and do view source...do you see all that JavaScript? That all runs client side
Johannes is right to point out the difference for server vs. client. The server side stuff is what needs to scale.
As an example, the Microsoft Silverlight team has assembled a facebook client app in silverlight (using the Facebook public API). My point is, using todays technologies, it is entirely possible to write a web application targeting many different kinds of client technologies: classic web browsers (HTML/javascript), 'rich internet applications' (flex, silverlight), ...
See also the myriad of Twitter clients out there.
The company I work for has a large app in Flash that is used by Governments. It is very hard to maintain and does fail sometimes. The problem is all of the .fla and .as files that have to be altered just to make a small change. Yes, the app could have been built better but even so, it is still harder to maintain than an HTML/JavaScript front end.
While I love writing Flash/Flex apps, I believe they should complement a site and not be the site.
Using a good JavaScript framework like jQuery takes the Browser compatibility question out of the picture (for the most part) and allows a lot of functionality.
Flex is the GUI for the client. You still need server-side storage and that's what has to scale. The user interface could be in Flex, while most of your users won't like such interfaces.
You will have to do a custom version of your site for the iPad/iPhone.
There are other ways of moving load to the client side. Javascript will give you porting headaches, but less than moving away from the entire architecture like Flex.
OTOH when you get a million users you'll have the resources to reimplement your site.
I don't think you would see a performance advantage with a site like Facebook, because the content is highly dynamic, comes from many different places, and is created by many independent entities. Flash (and therefore Flex) is better for monolithic apps from a single source that don't need to change very often.
The default in Flash is to build everything into a single .swf file that holds everything. It is possible to break out of this default behavior, of course. You can make web service calls, pull in external components via the SWC mechanism, load static content via HTTP, etc. Nevertheless, it's not the default pattern, which affects how Flash development libraries and tools work. Besides, the more of this you do, the less of the "run everything we possibly can on the client side" benefit you get. It gets soaked up in HTTP connection overhead.
The default on the plain old standards-based web is to store all assets separately and assemble them dynamically at the client. This is one reason the web is slow -- again, all that HTTP connection overhead -- but also why it is flexible and dynamic. It mates well with a site like Facebook which requires constant evolution by a lot of independent developers.
I say this having developed a Flex app, which I am happy with. Only one person -- me -- has to maintain it, and it's naturally a monolithic app. It plays right into Flex's strengths.
Let me start off by stating that I am a novice developer, so please excuse the elementary nature of my question(s).
I am currently working on a Flex Application, and am getting more and more confused about when to use server side scripting, and when to develop web services. For most of the functionality I am working on, I am taking various files from the user (client), uploading to the server for processing/conversion, then sending back to client in new format.
I am accomplishing most of this using asp.net generic handlers (ashx) files, but not very confident this is best practice. But at the same time, does making web services make any more sense? What would be considered best practice for this? Any suggestions would be greatly appreciated.
The way I look at it is as follows:
Web Services mean Established Best Practice.
For most of our development, we don't need to create "Web Services", or what I'm thinking when I think REST, SOAP, and the Twitter API. You only need to start doing that once you've got something you're going to be using every day for years.
Clean and DRY code will Lead you to Creating a Web Service
If you spend the time to clearly define the parts of your upload-process-render Architecture, and you find that it can be applied to almost everything you are doing, then all you need to do to make it a Web Service is define a clear, 1-2-3 set of rules for using the system (GET/POST data, etc.). As long as you are consciously building an architecture the whole way, you'll end up creating a Web Service if it's worthy. Otherwise there's no need.
It sounds like you have a clear workflow going, I don't know anything about asp.net though.
As far as it being confusing sometimes, and best practices, I suggest the following:
Create a Flex Library Project for your "generic ashx file handling" Flex classes. Give it a cool, simple name.
Create a .NET Library Project that encapsulates all the logic for your server-side file processing. Host it online and make it open source. I recommend github. Test it as you go, and document it, its purpose and the theory behind it.
If you don't have to do anymore work at this point, and it's just plug and chug, then you've probably arrived at something that might become a Web Service, though that's probably a few years down the road.
I don't think you should try to create a Web Service right off the bat. Just make some clean and reusable code, make a few examples, get it online and open source, have others contribute and give feedback, and if it solves a specific problem, then make it a web service. You can just use REST for now probably, and build your system around that. RestfulX is a great library for that.
Best,
Lance
making web services without any sense make no sense ;)
Now in the world of FLEX as3 with flash version 10, you can easily read local files, modify them with whatever modifcation algorithm and save local files without pinging server.
You only have to use webservices if you want to get some server data or to send some data to server. that's all.
RSTanvir
Flash / Flex uses a simple HTTP POST approach for file uploads, so trying to do that using SOAP web services will be problematic. Your approach of using ASHX here sounds reasonable to me.
To send / receive data that isn't file based (e.g. a list of files the user has uploaded previously), I would recommend looking at the open source Fluorine FX library. Fluorine uses AMF which is a highly performant way of doing data transfer with Flash. It's also purely configuration-based, which means you don't need to code against any of its APIs, just configure Fluorine to expose your .NET service classes. You could easily add attributes to those same classes to expose them as SOAP web services via WCF if you need that in the future. I would not recommend using SOAP with Flex however, due to the performance losses and also because the Flex implementation of SOAP has a history of bugs and interoperability problems.