RE: Thoughts on Flash

Posted by Redth | Posted on 29-04-2010

Category : MonoTouch, iPhone

Tags: , , , ,

I don’t want to get into details of why Flash is or isn’t great, and why it is or is not Apple or Adobe’s fault. However, I don’t prefer flash for the main reason that there are open standard alternatives (debatable to some point) that should be used instead. I haven’t had flash in anything I’ve made in years, and I don’t believe I’ve missed it.

However, with respect to the iPhone OS, we need to sort out some confusion about flash. There’s really two issues at hand:

  1. Flash for website content (eg: Embedded flash objects)
  2. “Flash” (quotes intentional) native applications using a cross compiler

Number 1) is a no brainer. I’m not unhappy that flash would be blocked in the sense of embedded web objects, other than the fact that it is a slight disturbance as I wait for websites to get with the program and stop using flash. Let’s face it, that’s the trend anyways, so let’s speed it along! Javascript, Ajax, HTML5 have effectively replaced the need for Flash web objects in most cases. I agree with several reasons Steve cited here, Flash web objects are not a good fit for mobile devices. Fair.

Second (2), is a completely different beast. Basically Adobe wrote a compiler that lets users code/design in ‘Flash’ which gets compiled down into a native binary much the same as any obj-c app in the end. In my opinion, there’s every opportunity for ‘Flash’ in this sense to make quality, high performance native applications. So the ‘performance’ of flash for native compiled apps is not a very good argument for Steve to make. He uses the confusion of flash on the iPhone OS in this case to prove a false point.

Now, Steve does mention in his letter:
“We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.”

I don’t think this is a fair argument either, for one simple reason: Let the market decide

  1. If a cross platform tool doesn’t implement a specific platform’s features and enhancements, that means I will decide not to use it myself if I don’t think I can produce a good enough app with it. So, supply and demand. The makers of these tools will be forced to ‘keep up’ if they want to stay in business.
  2. If someone does release an app that doesn’t implement specific platform features, that leaves the market wide open for someone else to make an app that does implement these features. Let competition sort it out.
  3. Finally, we all know Apple is the ultimate gatekeeper to the AppStore. If someone submits an app that performs badly, doesn’t adhere to UI standards, or does not implement iPhone specific features it should, they can reject the app on a case by case basis. In fact they already do this to a large extent.

Steve suggests Apple’s ultimate
“motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications.”

I can’t speak for Flash on the iPhone here, but I can speak for MonoTouch (which allows developers to write C# code to create native iPhone apps):

  1. MonoTouch stands on the shoulders of the iPhone OS. It interacts with iPhone Frameworks and API’s, using Apple’s own User Interface elements and libraries.
  2. MonoTouch levitates above the shoulders of the iPhone OS. For example, it’s had regular expressions and garbage collection (memory management) since it was released for iPhone OS 3.x. Apple’s own framework is only adding regular expressions in 4.0 and still doesn’t have memory management.

To get back on track, this isn’t a rant about why MonoTouch is better than Obj-C (though I love it so). But it goes to show that quality applications that perform well and conform to apples’ standards can be made with more than Steve’s pet language. It’s not the language that makes an app good or bad, it’s how it was made. There are plenty of examples of terrible obj-c apps out there.

Conclusions.

I can’t condemn Apple for not making Flash embedded in web pages work for Mobiel Safari. Their reasons are numerous and not unfounded.

I will condemn Apple for trying to play Mobile God once more by telling the Market what it would decide on its own. There’s no need to actively block Flash, MonoTouch, Unity, etc. Let the market decide with its wallet. Developers won’t use tools that suck, users won’t buy apps that suck, competition will weed out apps that aren’t as good as they could be, and Apple can still deny Apps and hold the ultimate key to the AppStore, regardless of what language they were written in.

The Truth Behind Apple banning Flash, MonoTouch on iPhone OS 4

1

Posted by Redth | Posted on 14-04-2010

Category : MonoTouch, iPhone

Tags: , , , , , , , ,

The real reason behind Apple’s changes to the  Developer Agreement is to keep the iPhone OS a unique, and exclusive platform.  Of course, that’s just my opinion.

There’s been much speculation about Apple’s intent with the new iPhone OS 4 Developer Agreement.  The popular opinion, and one which Apple is happy to publicly portray is that tools like MonoTouch, Flash, Unity, Torque (and there are others) somehow are responsible for creating slow, low quality apps with non-standard user interfaces that don’t take full advantage of the platform’s features.

Some Background Information
For a developer, the idea of code once and compile for multiple platforms has always been an elusive oasis in a desert of clumsy non-standard interfaces, and overly generic functionality.  It’s hard to get the best of both worlds, and often the best a developer can do is to build some common functionality with a cross platform language into a library that they can access code from with user interfaces for specific systems/devices, eliminating a good chunk of tedious work for much of the logic or ‘guts’ of their application.

Adobe’s Flash has been doing a pretty good job lately of trying to make this developer dream come true.  Adobe AIR accomplishes true cross-platform compilation pretty well and even has extensive integration with all the systems it is supported on.  They’re taking this one step further with Flash CS5 and apparently targeting several major mobile platforms, including the iPhone and Android, giving developers the ability to create their application once, and have it look, feel, and function the same across platforms.  I think it’s extremely important to mention here that Flash for the iPhone is not really Flash.  It’s simply a flash app that’s compiled to a native iPhone application.  So when people argue that flash is slow, and prone to crashing, that’s not a legitmate concern since it’s not really flash we’re talking about!

MonoTouch takes a different route by simply allowing code to be written in C# while targeting specific iPhone libraries.  MonoTouch gives developers access to all the same API’s that obj-c people have access to.  In fact, MonoTouch can even export an application to an XCode project.  In short, MonoTouch uses the XCode toolchain, does not try to reinvent user interfaces, and generally, produces very fast, standardized applications that too, compile into native iPhone applications bound to native iPhone API’s. 

So What’s the Big Deal?
In any case, there’s a good chance you’ve downloaded an application made with a tool like MonoTouch already.  Ever heard of Zombieville USA?  Well it was made with Unity, which borrows some of Mono’s functionality, the thing that powers MonoTouch.  My point is, apps made in these other languages are not necessarily any slower, or buggier than a good old objective-c app, and Apple could and should evaluate performance and bugginess of apps on an app by app basis, so arguing that these tools produce inferior applications is not a real excuse.

Think about this.  Why do people buy the iPhone?  It’s a nice piece of hardware, sure, but so is the Nexus One.  It’s got a nice operating system, but Android does some things better than it (eg: Notification organization).  People have an iPhone because of the Apps.  It’s Apple’s cash cow, and they need to hold onto it.  The only thing that truly sets them apart is the fact that there’s so many apps that don’t exist for Blackberry or Android, and that there’s so many apps that are better on the iPhone than their Blackberry and Android counterparts. 

Now imagine a bunch of flash developers start using Flash CS5 and all of the sudden they start making apps for the iPhone and Android at the same time, and that their apps look, feel, and function exactly the same on both platforms.  Now, do you still really want an iPhone?  Many people may still prefer the iPhone for various reasons (they are already comfortable with it, or Apple has already locked them into their ecosystem with iTunes, etc.), but many more people would feel free to move to another device.  This is not a new concept for Apple.  They’ve been making money by charging premium for their products based on the software and experience associated with their hardware.

The only thing I might give Apple some slack about is the possibility of Flash de-standardizing the user interface of the iPhone OS Platform.  It’s generally not a great thing to have every app with a unique interface and no consistency between them.  However, Apple could address this issue by rejecting apps on an app by app basis if they do not conform to user interface standards (similar to my previous sentiments).

What about MonoTouch?  The rest of the tools are just collateral damage.  Apple may not specifically care about killing them off, as MonoTouch for instance doesn’t threaten to make apps look and feel the same across all platforms, but for whatever reasons (perhaps legal), it’s easier to paint a broad stroke and wipe out everyone. 

Bottom Line
The key to Apple’s iPhone success is exclusivity, and it is in their shareholders’ best interests to maintain this success.  Keeping out apps that are identical across platforms means that Apple’s platform stays unique and keeps their users locked in.

Any negative press and lost app revenues from pulling apps that Apple incurs would ultimately be a minor setback compared to the gains from keeping the ball in their court in the long run.

I’m still optimistic about the situation and hope that Apple relents and allows the likes of MonoTouch to stick around.  There’s not really any certainty either way about the situation until Apple makes their stance more clear.

What do you think?

Is MonoTouch now Dead in the water? What does Apple’s new iPhone Developer Agreement mean?

33

Posted by Redth | Posted on 09-04-2010

Category : MonoTouch, iPhone

Tags: , , , , ,

Apple iPhone vs. Novell MonoTouch

Don’t Panic Just yet!

Novell hasn’t made any official comments yet on the new Apple iPhone Developer Agreement. I’m not sure if it’s technically covered by the NDA or not, but until Novell is in a position to make an official statement, I decided to write up something to keep some of the people up to date who are asking about it.

Here’s the source from the agreement:

APIs and Functionality:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and
must not use or call any private APIs. Applications must be originally written in Objective-C, C,
C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C,
C++, and Objective-C may compile and directly link against the Documented APIs (e.g.,
Applications that link to Documented APIs through an intermediary translation or compatibility
layer or tool are prohibited).

First of all, we need to understand what Apple’s true intentions are regarding this change to the agreement. Are they trying to prevent things like Adobe Flash’s new iPhone compiler, which could introduce a bunch of non-standard interfaces (not UIKit based) to the app store? Are they trying to prevent inefficient or poorly designed intermediate application layers from slowing down peoples’ devices?

If something like this is the case, MonoTouch should have good reason to stand, given that it binds the native UI’s and performance is great. Novell is currently trying to figure out what Apple’s intent is with this new agreement. Only once this is known, can they make a proper assessment of the situation. There are some others reaching out to Apple as well on the same issue. I believe Novell has some contacts within Apple who were excited previously about MonoTouch (although they could not officially endorse it), so hopefully this gets us some more disclosure on the issue sooner than later.

In the meantime, here are a few points floating around that we should consider:

  1. Apple is notoriously selective in enforcing their rules, so depending on their intent, they may be perfectly fine with monotouch continuing on, but stopping others (*cough* Adobe Flash)
  2. There’s some wiggle room in the current wording of the agreement for MonoTouch:
    1. MonoTouch does not technically “directly link against” Documented API’s
    2. “Originally written in…” is pretty vague. That could mean ‘Hey, I wrote my app in Obj-c then I rewrote it in c#’ (Yes, I know this is a stretch)
    3. MonoTouch’s main entry point is entirely written in C, so technically, it was “Originally written in C“
  3. MonoTouch compiles down to a native binary and there are some steps that are going to be taken to make MonoTouch apps have very little evidence that they were created with MonoTouch. It’s going to be difficult for apple to enforce this rule in such a case.
  4. Unity which has some parts of mono in it, has been used for several very successful games. Apple would be shooting themselves in the foot, although they could technically enforce this rule for MonoTouch but let Unity slide.
  5. Apparently every game produced by EA on the App Store would be in violation of the terms due to the fact they use Lua for scripting.
  6. The new agreement does NOT cover iPhone OS 3.2 and earlier. You can still compile apps for those OS versions under the old agreement without issue. Apparently all Developers must accept this new agreement by April 22nd.  The agreement itself does not specify a particular version, so it seems all versions may be affected.
  7. The new agreement does NOT appear to affect Enterprise Distribution
  8. There’s another note in the agreement (3.3.2): “An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.”… This could mean that any apps using any third party libraries or frameworks (think anything using Tapku, or Three20, and the list goes on) is in violation of the new agreement.  Can Apple really remove all of these apps too?
  9. TechCrunch reported (http://techcrunch.com/2010/04/08/adobe-flash-apple-sdk/) that Unity has stated they have a great relationship with Apple and expect nothing to change.

So the verdict is right now is simply: keep the status quo, and don’t panic until we know that the sky is actually falling. In the meantime, the MonoTouch team is pushing ahead with binding the 4.0 API’s and are quite excited about it.

Let’s not draw any conclusions until the dust has settled!

MonoTouch: HTTPS POST

1

Posted by Redth | Posted on 08-09-2009

Category : MonoTouch, iPhone

Tags: , , ,

Here’s some code binding to do a HTTPS POST in MonoTouch with the unbound NSMutableURLRequest, since the HTTPS in the MonoTouch stack is not yet working.  You should call the method like: “Http.HttpsPost(“http://url.com”, “var1=something&var2=anotherthing”); ” where the second argument is a querystring format of the post variables you want to send.  Here’s the code:

using System;
using MonoTouch.Foundation;
using MonoTouch.CoreFoundation;
using MonoTouch.UIKit;
using MonoTouch.ObjCRuntime;

namespace MyProject
{
public class Http
{

public static string HttpsPost(string url, string postData)
{
//Instantiate a NSMutableURLRequest
IntPtr nsMutableRequestPtr = Messaging.IntPtr_objc_msgSend(new Class("NSMutableURLRequest").Handle, new Selector("new").Handle);

//Since NSMutableURLRequest subclasses NSUrlRequest, we can use NSURLRequest to work with
NSUrlRequest req = (NSUrlRequest)Runtime.GetNSObject(nsMutableRequestPtr);

//Set the url of the request
Messaging.void_objc_msgSend_IntPtr(req.Handle, new Selector("setURL:").Handle, new NSUrl(url).Handle);

//Set the HTTP Method (POST)
Messaging.void_objc_msgSend_IntPtr(req.Handle, new Selector("setHTTPMethod:").Handle, new NSString("POST").Handle);

//Make a selector to be used twice
Selector selSetValueForHttpHeaderField = new Selector("setValue:forHTTPHeaderField:");

//Set the Content-Length HTTP Header
Messaging.void_objc_msgSend_IntPtr_IntPtr(req.Handle,
selSetValueForHttpHeaderField.Handle,
new NSString(postData.Length.ToString()).Handle,
new NSString("Content-Length").Handle);

//Set the Content-Type HTTP Header
Messaging.void_objc_msgSend_IntPtr_IntPtr(req.Handle,
selSetValueForHttpHeaderField.Handle,
new NSString("application/x-www-form-urlencoded").Handle,
new NSString("Content-Type").Handle);

//Make our c# string into a NSString of our post data
NSString sData = new NSString(postData);
//Now get NSData from that string using ASCII Encoding
NSData pData = new NSData(Messaging.IntPtr_objc_msgSend_int_int(sData.Handle,
new Selector("dataUsingEncoding:allowLossyConversion:").Handle,
1, 1));

//Set the HTTPBody, which is our POST data
Messaging.void_objc_msgSend_IntPtr(req.Handle,
new Selector("setHTTPBody:").Handle,
pData.Handle);

//Need to pass in a reference to the urlResponse object for the next method
IntPtr urlRespHandle = IntPtr.Zero;

//Send our request Synchronously
NSData dataResult = new NSData(Messaging.IntPtr_objc_msgSend_IntPtr_IntPtr_IntPtr(new Class("NSURLConnection").Handle,
new Selector("sendSynchronousRequest:returningResponse:error:").Handle,
req.Handle,
urlRespHandle,
IntPtr.Zero));

//Get the urlResponse object
// Get this if you need it
//NSUrlResponse urlResp = (NSUrlResponse)Runtime.GetNSObject(urlRespHandle);

//Get ourselves a new NSString alloc'd, but not init'd
IntPtr resultStrHandle = Messaging.IntPtr_objc_msgSend(new Class("NSString").Handle, new Selector("alloc").Handle);

//Init the NSString with our response data, and UTF8 encoding
resultStrHandle = Messaging.IntPtr_objc_msgSend_IntPtr_int(resultStrHandle,
new Selector("initWithData:encoding:").Handle,
dataResult.Handle,
4);

//Finally, get our string result
return new NSString(resultStrHandle);
}

}
}

Another Blog? Riiiight…

Posted by Redth | Posted on 10-07-2009

Category : Rambling Man

Tags: , , , , , ,

Hello Como

In the event that there may be any actual captive audience (or anyone at all really), I have decided to create yet another blog.  Yep, you heard me, another blog!  Well, like you even read the ones before.  I just as well could of said “Hello Interweb, I am here!” and you would have believe this was my first blogging attempt.  Either way you would have thought “I give it a week before it goes to bloggy heaven like all the other blogs out there”.

Well, to tell you the truth, I hope that doesn’t happen this time.  Actually, there have been a number of things I would have liked to blog about recently, but didn’t really have an outlet.  For starters, there’s the iPhone Apps I’ve been working on, which have led me to learn a lot about various technologies such as Mono, Cloud Computing, IMAP, and Obj-c (eww).  So from time to time I’ll be publishing tips I learn.

So, let this be the start of something beautiful (or at least tolerable)!

SEO Powered by Platinum SEO from Techblissonline