Forgot your password?
typodupeerror

Comment: Re:People expecting their marketing for free (Score 4, Interesting) 140

by maccodemonkey (#47570725) Attached to: Is the App Store Broken?

Too many people want to get rich by selling apps and expect Apple to pay for the marketing of their apps for free on the App Store.

I don't think this is quite what people are expecting. Rather, the problem is Apple directly prohibits most ways that an app can be promoted. Want to do a demo? No great way to do it in the app store. A trial? Forbidden. Want to offer a download directly from the developer? Nope.

So really what developers are requesting is simple: If Apple wants to directly hand hold the distribution and retail channel of an application, they either need to improve visibility for applications within that retail channel, or give developers more flexibility in how they can market applications. Apple isn't entirely responsible, but because they want developers to be so reliant on their store front, the argument is that Apple needs to actually provide a good store front to make that trade off worth it.

It would be like if you struck a deal with Target where they had full control over how your product was sold and exclusive rights to sell it, and then they stuck it in a dark corner of their store and never sold a single unit.

Comment: Re:Too many apps, too much appcrap (Score 4, Informative) 140

by maccodemonkey (#47570681) Attached to: Is the App Store Broken?

Question for you, as someone who has developed a mobile app:

How much harder is it to optimize a mobile version of the webpage vs writing an app from scratch and getting it approved for App Store release?

Mobile developer here who has done hybrid apps, Android apps, iOS apps, web apps, etc.

It's hard.

Web apps do not get the native scrolling mechanism, so scrolling feels very funky in web apps. Web app developers write their own inertial scrolling mechanisms to try to deal with it, but web apps always feel wrong as a result.

You also don't get access to a lot of native functions. No barcode scanning. No access to the user's preloaded Facebook account (with authorization, of course.)

There is another problem in that, especially on Android, web technologies are just badly supported. It's getting better in more recent versions of Android where Chrome is actually the engine used end to end by everyone, but earlier versions still on Google's old ass version of WebKit blew chunks.

Loading can be a problem as well. Real apps by definition cache a certain amount of code and resources on the device. A web page has to fetch all resources from start to finish. So while a real app has it's loading UI cached on device, and can display it right away when the user taps a link, a web page has to go fetch a UI over the network to display a loading UI for the operation the web app is about to do over the network. Gross.

The other really messy thing is a real app is pretty easily able to figure out what kind of device it's on and render content accordingly. Web apps can kind of guess what type of display/device they are running on, but again, it can be messy. Especially with new things coming like Adaptive UI/multi windowing coming on iOS where your window or screen size may have no real connection to what kind of device you're running on. Web pages at this point basically assuming they're always rendering full screen on mobile, and do their layout computations based on that, but that looks like it will change on future iOS and Android devices.

You also have a problem with native widgets. If I code a real iOS app, if I run it on iOS 6, it looks like iOS 6. If I run it on iOS 7, it looks like iOS 7. I don't have to create new assets, the app automatically ingests the correct look from the widget set built into the OS. With a web page, I get the "joy" of building my widget set from scratch, and trying to make it at least resemble the system UI widgets the user has been trained to use. And better yet, if I make my web app look like an iOS app, I suddenly have a bunch of Android users unhappy my web app looks like an Android app.

Finally, web apps don't offer any way to be embedded as extensions on iOS, or activities on Android. You can kind of fake it with some really really ugly URL handling handshaking, but this is really problem prone.

TL; DR: Mobile web frameworks/browsers are still immature, and don't offer basically mobile specific functionality that's needed to do apps well. It's not a problem of it being hard to do a web app just as good as a native app, it's a problem of it being impossible because the feature sets just aren't there.

Comment: Re:Don't repeat yourself in a multilingual project (Score 1) 168

Online games won't play unless at the latest patch level, for example.

Because the user is using the application during a 2-hour period of having no access to the Internet.

These are mutually exclusive. Online games stop you from doing client side things because they online. An offline application can't know that validation has changed or there is an app update because it's offline. At that point, what do you do, toss out any data the user entered while they were offline?

One easy fix (again): Do your validation on the server end only. Save the data locally, and when the user goes to submit it and it fails, then you throw an error. User doesn't lose any data, and your validation will always be good.

So your suggested workflow is just to let the user enter grossly invalid data for two hours then have the server present pages of error messages once a connection is reestablished.

As I noted above, there isn't really a way around this. Even if I follow your approach, when the client and server versions mismatch because the user was offline they'll get the same pages of errors. An offline user can't get a client update to fix the client side validation because again (drumroll) they're offline.

And, when they come back online, and they get the automatic update, they now have a local user database chock full of invalid data according to local validation. Do you just toss out all that data now because it no longer meets local validation? Or are you intentionally going to punch holes through local validation to grandfather now broken data in?

Boy, I hope your QA team has a large alcohol budget and the world's largest whiteboard for their validation testing matrix.

Hence the growth of Node.

It's true Node is growing, but again, data validation is usually either trivial enough it can be done on the client end in any language, or complicated enough you probably don't want to be doing it on the client end any way.

Comment: Re:Don't repeat yourself in a multilingual project (Score 1) 168

I don't usually see server architectures and client architectures sharing too much in the way of logic code

Input validation logic and any logic related to offline use needs to be the same (or at least provably identically behaving) on server and client.

I don't buy that's a reasonable excuse to force the client and server to be the same language.

First off, I don't buy that a client necessarily needs to do validation at all if the server is doing it. In fact, if you're doing complex validation on the client end, I think that is a Bad Thing (TM). What if your validation is wrong? Well you could just fix your server. But now your client's validation doesn't match, unless you're going to go around and force all your clients to update. Maybe at gunpoint or something. Who knows. But regardless, your client is going to think input is valid, and your server won't. Have you handled that case? What does that UI response look like? Have you unit tested it? Were you silly enough to think if it passed validation on the client end, it MUST pass on the server end? Cause if you did, you're screwed.

So I guess my simplest answer would be, if you need to do complicated validation why the heck are you doing it on the client? Just send it to the server, and then let the server return an error. That way you can fix your validation quickly server side if anything goes wrong, and you don't end up in test case hell in case the server and client disagree. You can also update your validation without touching your client code. And it really reduces your test cases and simplifies your unit testing flow.

For very simple validation (i.e. a credit card is always X number of digits, or a user needs to fill in these fields before they can press the submit button), I could see doing client side work. But that validation is so simple it's not hard to re-code. It's also usually so tied to the UI layer, you're going to be writing a lot of platform specific code any way.

I also still don't buy that being able to share code like that is worth the cost of locking entire ecosystems to a language and stifling language development in favor of a monoculture.

Again, if this is the metric we're working on, I could just take it up one level and say everyone should learn JavaScript instead of Java (and everyone should stop using Java) because you can't run Java in a web browser... Well... I take it back. Maybe it's an argument for the return of Java applets instead. :)

Comment: Re:Don't repeat yourself in a multilingual project (Score 1) 168

An application can be separated into logic and presentation, or model and view, however your framework prefers to describe them. A program may require separate presentation for each platform, but versions of a program for multiple platforms should ideally share the logic. But some platforms strongly recommend or even require use of certain languages. How can a programmer follow the rule of not repeating yourself to share logic across languages? Say I developed a game in Java or Objective-C but I want to port it to a Microsoft platform that allows only C#. (In theory it allows any language that compiles to verifiably type-safe .NET Compact Framework bytecode, but in practice that means C#.) How would I go about making and maintaining that port so that fixes to defects in the logic of the version on the original platform propagate to the version on the Microsoft platform ?

I don't think writing logic should be a gating factor that keeps a developer from using the right tool for the job, or keep a developer or a community locked in single language programming hell. There are edge cases (I've worked on an Android/iOS app that kept a bunch of code in JavaScript because it runs on both), but this doesn't even make the answer automatically "Java". I could very well say that developer should just go learn JavaScript because it runs on everything.

But more to the point, I don't usually see server architectures and client architectures sharing too much in the way of logic code, and the code they share typically isn't that complex, and doesn't usually require much work to port from one language to the next.

Comment: Re: Not worth it (Score 4, Informative) 168

Android Java knowledge is reusable for... Server side development?

The biggest time suck for learning a new platform is the platform itself, not the language. If we're comparing platforms, Android is like programming on the moon, and server side development is like programming on Saturn. A new programming language should only take a week or two to learn. The platform takes years. Android doesn't have much in common with a web platform. Unless Tomcat got an API to do mobile UI and touch handling, and Android got an API for failover and distributed services, they don't really have much in common at all.

If a developer is scared to cross to any platform because they don't want to be multi-lingual, they're doing it wrong. Java, Obj-C, Swift and C# are all pretty much the same thing, just with some syntax changes. Heck, there is even a family tree there. Java was based on Obj-C, and C# was based on Java. Swift is based on all of them.

Comment: Re:Or upgrade to llvm ... (Score 5, Insightful) 715

by maccodemonkey (#47544783) Attached to: Linus Torvalds: "GCC 4.9.0 Seems To Be Terminally Broken"

Debian people should probably downgrate their shiny new compiler.

Or upgrade to llvm. Being above to compile with either gcc or llvm would be a nice option.

It's amazed me how attitudes from LLVM in the last few years has gone from:
"OMG WTF why is Apple doing their own compiler why can't they contribute to GCC they want to make everything proprietary"
To:
"Hey, LLVM is a pretty great tool."

I'm happy to see LLVM making such great strides.

Comment: Nothing new here (Score 3, Informative) 100

by maccodemonkey (#47538929) Attached to: Private Data On iOS Devices Not So Private After All

iPhones have always been able to sync data out of their secure storage to the user's computer since launch. How did people think USB sync worked? Magical leprechauns that flew out of your phone carrying the data?

Heck, one of these is the developer daemon that runs on the phone to install apps from Xcode. Again, how exactly did people think Xcode did that?

These tools all require the phone be logged in, and that the right key exchange take place.

I can't tell if the "security researcher" here is just trolling, has never actually used an iPhone, it is just stupid.

Comment: Re:iOS Management Tools for non-macs (Score 1) 126

I'd settle for OS X Server tools that work across subnets. Time Machine backup server and print server, for instance.

These tools actually work quite well... as long as all your clients are all confined to a single subnet.

You should be able to configure it all by IP, which works great across subnets. I have a few OS X services configured that way.

Comment: Re:iOS Management Tools for non-macs (Score 1) 126

I wonder if this means that Apple will finally port it's iOS management tools to run on something other than OS X server. Ever since Apple killed the XServe(and really even before that) this has been a major hinderance to wider scale enterprise adoption of iOS devices. The tools are actually quite good, but if you are forced to try to cram a bunch of mac minis somewhere or trying to get some mac pros in the server room, it's just a pain. Add to that lack of practical way to deploy OS X server instances on the cloud and you have enterprise customers just not interested in trying to screw around with iPhones. Hopefully this partnership will fix that.

They support third parties, a lot of which implement management on Windows and Linux servers.
http://www.enterpriseios.com/w...

IBM happens to be one of those vendors:
http://www-01.ibm.com/software...

Comment: Re:the executive can't just wave state law aside?? (Score 2) 382

by maccodemonkey (#47458735) Attached to: White House Punts On Petition To Allow Tesla Direct Sales

How many times has the President (any President) done exactly this? Since Jackson famously told the Supremes "now go and enforce it" the Executive has been able to give the Judicial the finger. How many times in recent memory has the Executive waived, changed, or broken existing laws regarding the new Health Care act?

The problem is that this isn't a federally enforced law, it's a state enforced law. Obama can tell federal agents to no longer enforce any of these laws, but that won't change anything in since the feds aren't the ones supporting these laws to begin with.

Basically you'd be down to what the government had to do to force racial integration: Send in the army to keep Tesla dealerships open and protect the Tesla dealerships against state law enforcement. While I'd like to see you, you can understand why that might cause problems in this political climate. There is also a decent argument that Obama might not have this authority because their is no Federal counter law to the state law. Any way you look at this, Congress needs to pass a law for Obama to do anything. The example you're giving is the reverse: a President ignoring existing federal law. Here, it's the opposite: Obama would have to make up new a new federal law to override state law that does not exist. Not really the same thing.

Comment: Re:noone trusts their cya legalese (Score 1) 134

could just as easily mean, 'we havent worked WITH govt agencies.. but when they told us to step aside and let their devs in to commandeer a subroutine, we turned a blind/black-box eye'

Pretty sure giving them any access to any box or building would legally meet the definition of "working with."

You have to give credit to Apple for making these statements, because if it comes out that they did help the government, these open letters could be used as ammo against them in a class action lawsuit. So either Apple is stupid for making these claims when a no comment would be a better option legally, or they're not actually working with the government.

From everything I hear, it's the second option. Everyone I know at Apple is obsessed with security and privacy, to the point where I don't see Apple willingly giving anyone access. I know that's just my opinion, but even before this NSA thing happened, they were crazy about that.

I think part of that is a lot of their employees have very... strong feelings... about the way Google does business. Apple doesn't even want the information available for them to data mine themselves. They're basically denying themselves the opportunity to inspect data so no one will ever sell user information and run ads. It seems like most these policy decisions were made before the NSA spying case, which makes me believe they were legitimate convictions. Either that, or the government was already bugging Apple, so Apple made these changes.

Comment: Let me guess... (Score 1) 143

China is going to shortly release a state sponsored phone running their own OS and hardware that is totally "secure."

It's understandable that a nation like China would want to get in on the cell phone industry more deeply. Being able to insure a monopoly in China by scaring everyone away from the competition would create a huge, profitable industry internally. I just have a hard time taking what they're saying at face value.

And yes, before someone mentions it, I know the US does similar things for their own ends.

Prediction is very difficult, especially of the future. - Niels Bohr

Working...