Hi I compiled an app in XCode 5 and all the UI changed. I was forced to customize the Navigation Bar and TabBar to make it look like iOS 5/6. Does Apple HIG prevent us from using Opaque Black navBar and TabBar in iOS 7?
Well no, it doesn't necessarily mean that if your apps are running in iOS7, it needs to immediately have the new look. You can use iOS 7.0 as your base sdk but you need to do a custom modification in your app to implement the look and feel of iOS5/6 (but this is a tedious process...not recommended). Using 7.0 SDK will transform all appearance of UI Objects into iOS 7.0 objects (flat, no bezels, borderless, etc).
If you aren't ready yet to accept iOS 7 design in your application, you can still build your app using iOS 6.1 SDK. This will retain the previous look and feel of iOS UI, and will still run on iOS 7. Be careful though, some fonts (like Hirakaku pron) change their line spacing when they are run in iOS 7 (even though it is compiled against iOS 6.1). You may wanna do a forward compatibility check in iOS 7 for your iOS 6.1 Base SDK application.
(Cons of using iOS 6.1/6.0 as Base SDK: We still do not know if (or when) Apple will restrict submission of apps into iOS 7 only. But for now, uploading apps in iOS 6.1/6.0 is still ok.)
Summary:
Using iOS 7.0 as Base SDK: (Use Auto-Layout to properly design your objects)
When you run application in iOS 7.0 device: UI objects will appear flat (NEW UI LOOK)
When you run application in iOS 6.1 device and below: UI objects will retain their OLD LOOK
Using iOS 6.1/6.0 as Base SDK:
When you run application in iOS 7.0 device: UI objects will retain their OLD LOOK
When you run application in iOS 6.1 device and below: UI objects will retain their OLD LOOK
Related
I've been developing the same React Native app for about a year and recently I've noticed that on both iOS simulators, Android emulators, and physical devices, sometimes that little pop up that says "Refreshing" (that comes up when you actually make a change and save) constantly appears, even if I haven't changed anything.
It only happens sometimes and I can usually navigate normally throughout my app (though sometimes it crashes when this is happening, not sure it's related). Sometimes it just randomly stops though. It's very annoying at best and at worst I fear something is not right.
Since it happens on both iOS and Android, I feel like it must be something with React Native? I don't see anything in the logs about it and I haven't been able to find any issues whose solutions fixed things but here are the things I've tried:
Android Studio -> File -> Invalidate Caches...
Cleaning the build folders in XCode and Android Studio
Updating to latest versions (XCode 14.2 and Android Studio Electric Eel)
Restarting Xcode, Android Studio, and my computer
Increasing the Internal and SD Card storage to 1024 MB on an emulator. I'm unable to change the RAM or VM Heap.
Using React Native 0.67.4 and Ventura 13.1 on an M1 MacAir. It also happens on Monterrey 12.6.2 on an Intel Mac.
Anyone have any idea why this might happen? Thanks in advance!
I trying to use Windows.Gaming.Input API via C++/WinRT from Windows Console Application and it is not working as supposed with Xbox 360 Wireless Controller (reported as Xbox 360 Wireless Receiver for Windows (0x045e:0x0000)).
I got GamepadAdded event, then trying to read gamepad state via gamepad.GetCurrentReading() and seems GamepadReading struct is not filled at all for Xbox 360 Wireless Controller.
Also I found that there is some strange error message on MSVS debug console:
onecoreuap\xbox\devices\api\winrt\pnpdevicewatcher.cpp(500)\Windows.Gaming.Input.dll!00007FFE453AABC7: (caller: 00007FFE453AA367) ReturnHr(1) tid(4e04) 80070006 The handle is invalid.
Xbox One Game Controller (0x045e:0x02d1) is working fine though.
What is wrong with my code? Or this is bug in Windows?
Code is here: https://github.com/DJm00n/cppwinrtgamepad
Using Windows 10 1809, MSVS 2017 15.9.9, cppwinrt v1.0.190211.5, Windows SDK v10.0.17763.0, xusb22.sys v10.0.17163.1, xboxgip.sys v10.0.17163.1.
PS: I also tried UWP Simple3DGameXaml app from https://github.com/microsoft/Windows-universal-samples repo - and both controllers works in it.
This is a known issue. Apparently this is caused by how focus handling works. Windows.Gaming.Input basically doesn't work for console apps as a result, but does work for Win32 or UWP apps that have a window in focus.
Note that the one case where the Xbox One controller worked for you is only because both the user was an admin -and- because you had developer mode enabled. It wouldn't work from a console app at all otherwise.
If you need game controller support for a legacy Win32 console app, you should use XINPUT. See this blog post.
In order to help us investigate this issue more clearly, could you please share your Visual Studio 2017 version to us? You can get version info selecting Help -> About Microsoft Visual Studio, then selecting Copy Info from the right side of the About dialogue.
Could you please check if you can reproduce this issue on 1903 with SDK 18362?
By the way, it will be better if you can upgrade your project dependencies as well, what you are using is an old version of the Microsoft.Windows.CppWinRT NuGet package: 1.0.190211.5. The current latest stable version is v2.0.190722.3.
Besides, the C++ Language Standard was set in project properties, but the value was not set. This should be set to ISO C++17 Standard (/std:c++17) under Project Properties -> C/C++ > Language > C++ Language Standard.
Thanks for your collaboration.
I downloaded the simulator for BB Bold 9930 (v. 7.1) at http://us.blackberry.com/sites/developers/resources/simulators.html
My Windows VM follows the system requirements at http://developer.blackberry.com/bbos/java/documentation/the_bb_smrtphn_simulator_447179_11.html, except for one thing: OpenGL 1.x compatibility, which I can't figure out how to test (see Windows 7 on Virtualbox virtual machine: is it OpenGL 1.x compatible?).
So installing this and launching C:\Program Files\Research In Motion......\9930.bat causes the following error to come up:
"An OpenGL 1.x + compatible video card with recent video drivers is required for graphics acceleration. Please try a lower graphics acceleration setting by navigating to the view menu".
Clicking on the view menu is impossible until I click OK on the modal dialog, but when I do so, the program immediately crashes with the message "BlackBerry Handheld Simulator has stopped working".
Is there any way around (through the command line, for instance?)
You should be able to force the simulator not to use the graphics acceleration at all (which hopefully would work around your problem).
See this BlackBerry forum thread here.
Basically, just include this in your simulator config file:
<?xml version="1.0" encoding="utf-8"?>
<fledge-configuration>
<BodyBuilder::opengl-acceleration>0</BodyBuilder::opengl-acceleration>
The setting of 0 turns off graphics acceleration. You can either turn it off by default in your simulators, or just in one particular simulator, by using the fledge-saved.conf file, or 9900-saved.conf file (for example, to change the setting on the 9900 simulator).
On a Windows system, these config files would be located somewhere like:
C:\Users\myname\net\rim\fledge-2\
I have built and deployed Dvorak SIP sample from C:\Program Files\Windows Mobile 6 SDK\Samples\PocketPC\CPP\ATL\dvoraksip location. The sample successfully deploys and registers and when I click on Dvorak from the SIP icon at the middle of the tray it is opened in Windows Mobile 5 emulator and some other devices except Pidion BIP-1300-GSM which is running Windows Mobile 5.0.
What is the reason?
I should mention that it is always deployed and registered successfully.
UPDATE
I put DebugMessage in all of the methods.
When I Deploy Dvorak, methods in dvoraksip.cpp are called on device like what happens on Emulator.
When I click the icon in tray in Emulator methods in dvorak_implementation.cpp are called correctly but nothing is called on Pidion device.
I don know what possibly went wrong on your side. There are some pitfalls when using this WM653 sample on Windows Mobile 5. When you switch to WM5 in VS8 configuration manager, the deployment settings have to been adjusted:
Do you have WM5 SDK installed within VS2008 too?
In VS8 ensure that you link ATL statically:
Here is my updated VS2008 project/solution of DVORAK SIP sample using WM5 SDK: http://www.hjgode.de/temp/dvoraksipVS2008_WM5SDK.zip
I tested that on a WM5 device (no Pidion, an Intermec CK60 running WM5):
I have seen that you posted the same question at social.msdn and who knows where too. If the pidion still does not work like a WM5 device, you should consider changing the model.
As an alternative you may use Richard Boling's NumPanel example of a SIP.
Here is the VS8 solution for WM5SDK: http://www.hjgode.de/temp/BolingNumPanel.zip
I have a Qt app that runs on OS X that has potential to go on the new Mac App Store.
I have reviewed the guidelines at https://developer.apple.com/appstore/mac/resources/approval/guidelines.html. I also saw a post here on SO about Java and the AppStore.
Has anyone else considered this with their own apps and whether or not the Qt framework will run afoul of the App police? You still have to stay within the Apple HIG, i.e. no theming and cannot use private APIs.
Still seems like a risky proposition over pure ObjC. Anyone else tempted?
My Qt app has today been accepted and is available on the App Store. So the answer is yes, Apple will accept Qt based applications.
Here's some information about my application. It written in C++ and uses Qt v4.7.2 under the LGPL license. The Qt frameworks are included in the app bundle (obviously, as LGPL requires I use dynamic linking instead of static). There are also some other frameworks, from Nikon and Canon, because its an app for remote control of DSLR cameras - see http:www.hartcw.com . These are only available compiled for Intel 32bit, hence this forces my app to also target 32bit, and so I have to use the 32bit Carbon build of Qt.
Regarding writing files to the local hard disk, it does not write anything to the bundle directory, but does write to this directory:
~/Application Support/Hart/Smart Shooter
It also writes Qt GUI state to this file (via the QSettings class)
~/Library/Perferences/com.hartcw.SmartShooter.plist
'Hart' is the company name as registered with Apple, and 'com.hartcw.SmartShooter' is the app identifier name, so I think this is what Apple checks against.
Also there were a couple of things I had to do regarding the plist file, see http://hartcw.com/francis/qt-and-the-mac-app-store
Infact it was accepted first time by Apple! It was in the 'waiting for review' stage for about 10 days, then transitioned to 'in review' for about 4 hours, and then went live on the app store.
Using Qt is no problem at all for creating an app for the App Store. All you have to do is to make sure that you are using Qt compiled with Cocoa and not Carbon.
EDIT: I've just found that there may be an issue if your application uses Qt plugins (as this apparently makes Qt write to ~/Library/Preferences/com.trolltech.plist which is outside the 'domain' of an App Store application.)