I have an IOS app that has 2 targets. 1 target is for Turkish store, and the other one is world wide.
One of the plist, I choose Localization native development region as "en". In the other one, I choose "tr".
In IOS7, everything is fine. But IOS6 doesn't understand which localization should be applied.
What is the right way to do this?
Related
While developing app with codename one with Netbeans IDE, I was running into this issue where the simulators were not usable except iphone 3. If I choose the simulator to be iPhone 5 or 6 or 6 plus, the simulator is so huge and only part of it appears on the screen and I couldn't even scroll.
Is there anyway to make the simulator to fit within the window sizes? I tried on Mac and Windows and I experienced the same result.
Please advise.
Uncheck the Scrollable option under the Simulalator menu. It's on by default since some artifacts might appear during scaling but for large skins there is no alternative.
At some point I seem to have a lost the ability to go to native iPhone look in the codenameone emulator. How can I get it back to normal?
I did have two themes in the theme.res file - I've tried deleting them both and creating a new native one called "Theme". I've also commented out all my initialization code in the before call for the Form, but it still looks like this:
Codename One migrated to iOS 7 as required by Apple: http://www.codenameone.com/3/post/2014/01/switching-defaults.html http://www.codenameone.com/3/post/2013/10/seven.html
To use the old simulator for the old theme just select Skins->More and select the old iOS 6 skin. You probably shouldn't though since you need to migrate to iOS 7 which most devices have already migrated to.
I have some apps developed using Xcode4.
When opening the projects and build them for the 5 simulator using Xcode5, most of the apps will look iOS7 style when built for 5 simulator while some still looks iOS6 no matter what I do
The apps are pretty much the same so I do not understand how to decide myself which style it is going to be.
Looking at the settings I do not see any difference.
The app which is built as a iOS6 like style seems not possible to change to iOS7 style, and some apps are built as iOS7 style as default and is not possible to change to iOS6 style using Xcode5.
Please help!
Depends, most of the standard UI elements are redesigned in iOS7 (UIAlertView for instance), you can't do a lot, if you want to keep the ioS6 look you should rebuild all these components by yourself.
Elements that adhere to the appearance proxy can be customized to look like pre-iOS7, but it will be a hard job.
In iOS7 you also have another "problem" to manage, by default all views are full-screen, this is simply to solve if you deploy only on iOS7, bit harder if you deploy for prior iOS7 and iOS7.
There i a way around... download the 4.6 version of xcode ance deploy only on iOS6, most of the UI elements will maintain the same aspect, it seems that Apple still accept <=iOS6 binaries.
I have a winforms application and was wondering whether I should attempt to move it to Windows store app (and WPF) or not. I would expect metro style apps to have the same potential as desktop apps, but what got me wondering is the fact that VS 2012 is not a metro app. It doesn't really surprise me much as every metro app I've seen so far look like a phone app that can't really do much and I can't imagine how VS would look like as a metro app.
Seems to me like Microsoft wants to slowly move everything to metro, otherwise I don't see the point on introducing a whole new visual experience just to get stuck with having to switch between metro and desktop, but even Notepad is still a desktop application. So my question is, basically, is every kind of application supposed to be movable to metro or is metro only for small phone-like applications?
I don't believe that Microsoft is intending every application to end up Metro. I see more lightweight types apps going to Metro. Heavy duty line-of-business apps will stay on the desktop side of things.
I do see an opportunity for writing both desktop and Metro style apps in enterprise environments though. Imagine this hypothetical scenario:
In an enterprise, I can see Accounts Receivable running the full-blown, monolithic, desktop application on their desktops just like they run them under Win7 because they’re needs are pretty extensive.
The receptionist will run a touch enabled laptop with a Metro app that is tied into just the corporate appointments.
The guys on the loading dock will be running Win8 phones that have the intake/outtake app showing schedules for deliveries and what not.
Managers and executives have Metro tablets that have an app that shows metrics: lots of pretty charts and graphs showing the current condition of what and how the company is operating in it’s different lines of business.
For the users that need the complexity, it’s desktop mode, but for the users that perform smaller, specific computer tasks, touch-enabled Metro apps for them.
Metro-style apps are for content consumption, like you would find on a tablet.
Classical desktop apps are for content creation.
I think metro apps are an additional feature and I do not think, that they are a serious replacement for desktop applications. If you want to deploy your apps to tablet PCs, phones or any other touchscreen/handheld devices, metro style would be a good choice. At the moment there are just not many consumers for metro apps as Windows 8 has not even come to the markets.
As you already mentioned, on desktop PCs metro apps are very uncomfortable and do not provide the full functionality as desktop applications can do.
So my question is, basically, is every kind of application supposed to be movable to metro or is metro only for small phone-like applications?
I don't think so, as this means automatically that many customers who have used previous versions of Windows would have to learn working with the metro interface.
Metro apps provide much more functionality than desktop gadgets have done in Vista, as they can be programmed using C# or other .Net languages, but metro apps use up too much space to be controlled with a simple mouse.
I recently did the Chris Coyier tutorial from the css-tricks.com weblog #38: Basics & Tips on Designing for the iPhone. Needless to say I got very excited and suggested to a guy that I do some code monkey work for that we could now offer iPhone websites to his clients. He said cool, but what about other mobile devices? good question. So what is the low down on designing websites for Android, Blackberry, WindowsMobile, etc? Are people bothering with the other platforms? Thanks.
Recent Webkit and Opera:
For iPhone Safari, Opera Mobile, and Webkit on Android development are similar (but not identical), and development for those is quite simple.
You can rely on CSS2.1 and JavaScript+DOM (but be careful with UI events). You might get away with serving your regular website with just few changes to stylesheets.
The trick is in serving of these stylesheets. Don't use User-Agent string.
Because some mobile browsers read handheld media, and some insist on screen styles and pretend to have 960px-wide screen (iPhone :/), you'll need to serve mobile stylesheet with both:
<link media="handheld" ...>
<link media="screen and max-device-width:480px" ...>
The latter is CSS3 Media Query – very useful and works with other mobile browsers too (you can use it in stylesheets with #media {}).
Don't rely on :hover or onmouseover because these events don't work on touch screens.
onclick is delayed, mousemove may not work. Custom DHTML widgets (dropdowns, sliders) and drag'n'drop won't work on touchscreens, unless you use touch events (which thankfully all newest browsers adopted).
Viewport
In addition to Apple's proprietary (and IMHO inflexible and violating separation between markup and layout) <meta name=viewport> have a look at CSS3 #viewport, which currently is supported in latest Opera as #-o-viewport and hopefully others will follow.
Simulators/Emulators
To test page in Opera Mobile, get the simulator (or just older desktop version and choose View → Small Screen).
Opera Mini is special, as CSS is re-formatted a bit and DHTML is executed on server-side, which doesn't always give results you'd expect. There's simulator available.
Android
You need Android SDK, fiddle with commandline to launch its clunky UI, download bunch of packages, create virtual device with dozen of irrelevant obscure settings, have patience for this monster to load and turn computer's fans into a quadcopter, and then you can sss..sss..slooowlyyyy test in the "Browser" (my Intel i5 is too slow to simulate Galaxy Tab - browser "stops responding" even before I finish typing URL)
It's easier to get a phone/tablet with Android and test on a real device (but avoid Samsung's Player "iPod" equivalent, as it's rubbish with obsolete software).
Android browser is really painful for anyone who doesn't love Linux way of doing things — just to read JS console you need to fiddle with remote debug connections and log filtering on commandline.
Firefox Mobile (previously Fennec)
There's simulator available (links for "Windows / Mac OS X / Linux" below mobile downloads are not the desktop version, but mobile-for-desktop-OS).
Simulator is very basic, Mobile Firefox itself is IMHO really good, e.g. overflow:scroll works great, while on WebKit-based browsers overflow implementation varies between very unintuitive and totally broken.
Pocket IE:
PIE for Windows Mobile < 7 is not the same engine as IE on Windows. It's mostly as primitive and buggy as IE4 was, but (barely) supports some surprisingly advanced properties like display:table.
It reads both handheld and screen stylesheets at the same time, violating the standard and shooting itself in the foot. If you're going to suppot PIE, then put link to handheld stylesheet last and reverse/override all the rules from screen styles in it.
Anyway, it's dead and it's hard to get an emulator.
Windows Phone 7 currently ships with IE7-alike, and Microsoft promised something of IE9 level later.
New (minority) BlackBerry
The latest WebKit-based BlackBerry browser is quite good, you can treat it as 1st-class citizen (see WebKits comparison linked at the top).
Currently most popular BlackBerry & OpenWave, Blazer, etc.:
Before the BB OS6, it's a nightmare. Only basic HTML works. CSS works on some models, but is primitive and broken. JavaScript works only on some models and it's incredibly slow and lacking (forget about even basic DHTML).
There's free BB simulator available from RIM (annoying registration required). If you're unlucky, it'll launch properly once and then you'll have to completely reinstall it :)
The same thing is with hundreds of other mobile browsers on low-end phones (powered by likes of OpenWave, which has decent simulator) . You'll have to prepare 1-column basic HTML stripped down website for them.
Google Wireless Transcoder
Even if you create nifty (X)HTML optimized for every mobile device out there, users of Google Mobile Search will never see it!
Instead, every page will be proxied through "Wireless Transcoder" which brutally chops the code, stripping all stylesheets and scripts (regardless whether browser supports them or not), and even <font> :(