Apple should Develop a Flash Compiler

Posted on by
4

One interesting solution to the continuing public battle between Apple and Adobe over Flash support on its mobile platform would be for Apple to release its own Flash compiler, one that would allow a developer to create Flash applications without ever purchasing an Adobe product. Before you laugh, hear me out.

Neither company is open
What bothers me about the whole public fiasco is that both companies have been arguing that they support open formats – Apple in its preference for HTML5 and Adobe in its desire to publish its own applications freely to the iPhone – while both basing their own technology on extremely proprietary and closed formats, as seen in Apple’s recent closing of the iPhone and Adobe’s tight control of its Flash product.

The truth is, neither company wants their products opened for the world to use, but both companies demand the other open their platform. If Adobe was really serious about Flash as a ubiquitous platform, then they should donate Flash to a standards community that would open it to the world. Likewise, if Apple wanted anyone in the world to be able to develop on the iPhone, they would have created it as such and declared it an open standard.

Unfortunately, I agree with Apple
While I personally would love to develop iPhone applications using Adobe’s Flash-to-iPhone compiler (I really would!), I fully support Apple’s right to close the platform. Above all else, mobile platforms must be secure and Adobe’s iPhone compiler seriously threatens that security. The iPhone, like many other mobile platforms, is not open for the world to develop on, nor should it be.

There are many whispers that the government is investigating anti-trust violations over Apple’s blocking of Adobe’s iPhone compiler, but that would be ridiculous, since Apple does not have a monopoly on smart phones. In fact, the Android recently surpassed the iPhone in sales, leaving Apple in third place among smart phone manufacturers. Apple would have to be in first place with a clear monopoly on the market before I would support any government intervention telling Apple what it can and cannot do with its mobile platform.

Apple’s Flash Compiler
Since Adobe believes it has the right to freely develop on the iPhone while at the same time arguing Flash should be supported everywhere, one interesting twist would be for Apple to develop its own Flash compiler and even run-time. That would very likely upset Adobe and lead to a very interesting argument over proprietary platforms. Adobe could claim only they have the right to develop Flash applications, something Apple currently asserts over its iPhone application. On the other hand, Apple could claim that if the Flash platform is everywhere then it should be open for anyone to develop applications on, something Adobe likewise states about the iPhone platform.

And as an added bonus, Apple could develop this compiler as an iPad/iPhone application!

dbunit vs recreate schema

Posted on by
Reply

As I continue looking at writing integration tests for the back end of JavaRanch’s JForum install, I faced the decision of how to guarantee a clean database.  A previous post on the topic covers how to clone a postgresql database via the command line.

I was originally thinking about using dbUnit to import data.  I may still do that if I find myself needing a lot of data.  However, I realized it was more important to be able to recreate the table structure each time.  Our database schema changes regularly as we enhance tables and I don’t want people to have to update the exported dataset. The concept is to have the test create the schema/tables/data from scratch each time it runs.

Some interesting things in this infrastructure:

  1. JUnit suite wide setup – I had so much to say on this topic that I wrote a separate blog post on it.
  2. Main method – The main method is interesting because it provides the starting point. It sets up the database (more on that later) and kicks off all the JUnit tests. It uses the JUnit runner to benefit from JUnit’s reporting mechanism. I also added logging for the database setup in case it took a long time on someone’s machine. This turned out not to be a problem. At the moment, I’m leaving it “just in case.” 
    public static void main(String[] args) throws Exception {
long start = System.currentTimeMillis();
setUp(args);
long end = System.currentTimeMillis();
System.out.println();
System.out.println("Done setting up database in " + (end - start) + "ms.  Now running tests.");
System.out.println();
JUnitCore.main("com.javaranch.test.functional.All_JForum_Functional_Tests");
}
  3. Pointing to a test database– Many developers, including myself, have test data in their “jforum” database and wouldn’t appreciate the integration tests mucking around with it. As a result, the integration tests use a special “jforum_integration_test” database. This database has its schema recreated each run of the test. Conveniently, JForum has a property for the database name that all the code uses. Having the code update this in setup is sufficient. 
    SystemGlobals.setValue(ConfigKeys.DATABASE_CONNECTION_DBNAME, "jforum_integration_test");
  4. Tear down first
    A common pattern when integration testing is to call tear down before setup. Tear down drops the “public” schema. (which is where postgresql stores everything) Setup creates the schema and loads the DDL/SQL. This is done in a DatabaseController class to keep the All_XXX_Tests class uncluttered. For example:

    conn.prepareStatement("DROP SCHEMA public CASCADE;");
  5. Running a DDL file – This is a blog entry in and of itself. Which is good because I made it on

Conclusion
I’ve been using this test structure for a couple weeks now. It has served the purpose well and I expect it to live on. A nice side effect is that we find out very quickly if the DDL is incorrect in SVN!

GET vs POST and URL security

Posted on by
3

Is GET or POST more secure?  Like many things in computers, it depends!

Who are you trying to secure data against?

  1. The user in his/her browser
  2. People who legitimately see the URL
  3. Hackers

The user in his/her browser
This is the case that is usually discussed.   Some people will naively say they want to “secure” the data by using POST.  That way the user “can’t change the submitted data.”  Of course, this hooey.  Anything on the user’s machine is something the user can see/change.

People who legitimately see the URL
Many people have access to the URL such as in logs.  Having sensitive information in the URLs is a bad idea.  This actually happened recently at JavaRanch.  A user started a thread inquiring about a thread that linked to his but he couldn’t see the protected page.   At JavaRanch, as on many blogs, URLs look like “http://www.coderanch.com/t/493907/Ranch-Office/Could-anyone-enlighten-me-please”.  Luckily we had taken a precaution and used a shorter form of the URL for our private forum.  Otherwise information could leak out!

Similarly, social security numbers and other sensitive information should not be in a GET form submission because the information is then out of your control.  If at all possible, they should be kept on the server and never sent to the user’s machine in the first place.

Hackers
Hackers are a harder case because the hacking can be in multiple places.  For truly secure information, you have to use HTTPS.  For “medium” information, POST is still better than GET because URLs are easier to intercept than whole pages.

Conclusion

As a rule of thumb, POST is going to always be more secure than GET because it removes the “data in the URL” issue.  For some things, neither is secure enough.