The Apple job creation page is pure PR: they claim to have "created" or "supported" over 500.000 jobs.
It sounds like the kind of thing a politician would say. Because they even add transportation, health care and "the app economy"!
It's kind of like you claiming to be a job creator because you buy local and burn electricity.
Anyhow, what's interesting is that the App economy is estimated at 210,000 US jobs and Apple has paid over $4 billion to App developers world-wide, ever!
Assuming those $4 billion were all to US app developers in a single year, that ends up to about $19.000 / job in total or about $1600 / month / US developer if that amount is split over 12 months.
What this shows is quite interesting: the App economy isn't self-sustaining.
If the 210,000 US jobs are real then App Store sellers are burning cash.
Considering the money sellers make must follow some sort of distribution then most of those "app economy" jobs aren't even making minimum wage in profit.
Now, one might say: "yes, but those App creators are making money some other way -- perhaps they are giving the apps for free". I disagree. There are few brands that afford to have developers doing apps just so they make money in another way.
If you think about it Apple wants their 30% on every sale you make through the app. That's why the Kindle app removed their Amazon store button.
So it must only be that most of these "jobs" will go away once they realize there is no profit to be made. Or that most of these jobs don't exist to begin with and are nothing more than hobbyists coding after their real job.
It might be just a coincidence, but my company just dropped out of the iOS Developer Program. We were too busy with out other Java-based projects and iOS demand seemed to have leveled anyhow so it made no sense to keep paying those $99/year.
It might just be the start of a trend.
Saturday, March 03, 2012
Friday, March 02, 2012
Intellij needs to introduce the Lookup API
I'm looking today at the toolbar classes from IntelliJ IDEA and I'm surprised by the amount of instanceof I see.
For example,
That's just horrendous!
What they need to do is introduce a mechanism similar to the Lookup API from NetBeans.
Then, if object is a Lookup.Provider, just call
The above method becomes
and each of the individual classes (Project, Module, PsiElement, JdkOrderEntry, LibraryOrderEntry, ModuleOrderEntry) will have to add into their lookup the given Icon.
As it is right now, the existing code has a lot of imports. What looks like a little Swing module (com.intellij.ide.navigationToolbar) imports hundreds of classes from all over the place and seems to be a pain to read and maintain.
Truth be told, the code is from 2008 -- perhaps the newer stuff already has a similar mechanism.
PS: While I am a NetBeans guy, I'm not trying to start a flamewar. I actually want to see if I can reuse navigationToolbar but all these imports are making it really difficult.
For example,
NavBarPresentation.getIcon
looks like this:public static Icon getIcon(final Object object, final boolean open) { if (!NavBarModel.isValid(object)) return null; if (object instanceof Project) return PROJECT_ICON; if (object instanceof Module) return ModuleType.get(((Module)object)).getNodeIcon(false); try { if (object instanceof PsiElement) { Icon icon = ApplicationManager.getApplication().runReadAction(new Computable() { public Icon compute() { return ((PsiElement)object).isValid() ? ((PsiElement)object) .getIcon(open ? Iconable.ICON_FLAG_OPEN : Iconable.ICON_FLAG_CLOSED) : null; } }); if (icon != null && (icon.getIconHeight() > 16 || icon.getIconWidth() > 16)) { icon = IconUtil.cropIcon(icon, 16, 16); } return icon; } } catch (IndexNotReadyException e) { return null; } if (object instanceof JdkOrderEntry) return ((JdkOrderEntry)object).getJdk().getSdkType().getIcon(); if (object instanceof LibraryOrderEntry) return IconLoader.getIcon("/nodes/ppLibClosed.png"); if (object instanceof ModuleOrderEntry) return ModuleType.get(((ModuleOrderEntry)object).getModule()).getNodeIcon(false); return null; }
That's just horrendous!
What they need to do is introduce a mechanism similar to the Lookup API from NetBeans.
Then, if object is a Lookup.Provider, just call
getLookup().lookup(Icon.class)
.The above method becomes
public static Icon getIcon(final Object object, final boolean open) { if (!NavBarModel.isValid(object)) return null; if (!(object instanceof Lookup.Provider)) return null; Lookup lookup = ((Lookup.Provider)object).getLookup(); return lookup.lookup(Icon.class); }
and each of the individual classes (Project, Module, PsiElement, JdkOrderEntry, LibraryOrderEntry, ModuleOrderEntry) will have to add into their lookup the given Icon.
As it is right now, the existing code has a lot of imports. What looks like a little Swing module (com.intellij.ide.navigationToolbar) imports hundreds of classes from all over the place and seems to be a pain to read and maintain.
Truth be told, the code is from 2008 -- perhaps the newer stuff already has a similar mechanism.
PS: While I am a NetBeans guy, I'm not trying to start a flamewar. I actually want to see if I can reuse navigationToolbar but all these imports are making it really difficult.
Subscribe to:
Posts (Atom)
The Trouble with Harry time loop
I saw The Trouble with Harry (1955) a while back and it didn't have a big impression on me. But recently I rewatched it and was amazed a...
-
As Apache NetBeans became a top level Apache project and finished the incubation process I was asked for an interview and my photo. Only ...
-
I like making NetBeans dance: NetBeans - PalmOfMyHand - Dance Demo from Emilian Bold on Vimeo . The above video is a little somethi...
-
People will never bother to do anything manual unless absolutely necessary. This is why I believe the current NetBeans "empty" jav...