RIM has released a new Blackberry JDE4.7 after releasing the Blackberry Storm. Does the Blackberry storm support programs created using the previous versions? I've heard there have been a lot of changes in this version compared to the old ones.
And there have been complaints about Storm having many bugs.
Should I use 4.7 or keep using the older JDE?
Thanks.
Depends what you want to do. You'll actually get the rotation for free if you've designed your application's layout to be fairly resolution independent. When the device is rotated your layout and sublayout methods will be called again (or if you've just used built-in fields and managers, it's all automatic).
The big things you'll need the 4.7 JDE to do include:
Responding to specific touch events
(events which result
in e.g. focus going to a Field, or
scrolling, are automatically mapped
to the older APIs)
Detecting device
orientation (though again, layout is
already taken care of - this is more
if you want to use the accelerometer at a low level
to e.g. control a game or something)
Bottom line: backwards compatibility is in general very good, RIM has mapped the new touch interface to older APIs in a sensible way, and since the Storm hasn't quite taken off as the iPhone has (most people believe that the Bold and Curve are still better devices), stick with an older SDK unless you're doing a very Storm-specific application.
The Blackberry Storm should support programs created using the previous versions. Occasionally, though, programs will break, whether because of a bug in the new version or a now-fixed bug in the old version.
There had to be a lot of changes in the 4.7 API to support the Storm's new features.
Really, though, you should develop with the lowest JDE you can get away with, to avoid forcing people who might otherwise try your program to update first. On the other hand, of course, if you want to do a rotating interface, you're going to need the 4.7 JDE and the Storm.
Developing with 4.7 does have some issues if you've made any changes whatsoever to the way input is handled. If you've made any custom fields, you'll need to update them and have a different build for 4.7 vs < 4.7. There are more methods on fields, for example moveFocus(int x, int y).
If there's any text input anywhere, you're going to have to ensure that the virtual keyboard doesn't cover up or remove from view anything you need to be visible.
The autorotation of views is also sometimes an issue if you've done something manually on a screen and you don't want that to change during runtime, in which case there is a way to force the application into a particular orientation.
I've also noticed some issues with the simulator at least, when using GaugeField objects, that is, if you focus on a GaugeField, the focus cannot be removed. Not sure if this issue has since been fixed or what, but at least that's the way it is with my simulator.
Related
We are currently developing a multitouch multiuser application which runs on a big touchscreen table.
Obviously the application has a lot of animations and transformations included, i.e. moving and rotating UI elements around using touch gestures, menu opening animations, touch rotations etc.
To better understand what kind of Application this is going to be, here is a Video of a similar application with kind of the behaviour we are targeting (minutes 0:16 - 0:27): https://www.youtube.com/watch?time_continue=13&v=qIOR9FiL97w
Back in the days we used Adobe Flash for such applications, since it was the only way of getting good performance and interactivity but since flash is dead, what is the current best way of implementing such an application?
We tried game engines like Unreal Engine 4 and Unity but the support for multitouch is very meager and most of the gestures etc. have to be implemented yourself and also most of the common controls like scrollviews, carousel controls etc.
We also tried UWP which has good touchscreen support and implements most of gestures and behaviour you are expecting of a touchscreen application and almost all common user controls are already implemented but we got a huge problem regarding performance, especially on higher resolutions like 4K or 8K. The more controls and grids and layout we put in, the slower the application became and moving around and rotation etc. are very slow and only run on one thread. We had a look into the new Composition API but its very complicated and its not very clear whats the best way to combine XAML controls and composition API, also there is Win2D but it only provies basic functionality like drawing rectangles and also no touchscreen support, only through XAML.
So, is there any good Framework or API to implement applications like in the video I linked? Or is Flash still the best way? Is there a Qt library for such things or even Javascript? Or is even Android the way?
https://kivy.org
Kivy - Open source Python library for rapid development of applications
that make use of innovative user interfaces, such as multi-touch apps.
Cross platform, GPU Accelerated, comes with more than 20 widgets, all highly extensible.
(This question is mostly applicable to those of us developing iPhone apps without access to an iPhone 7.)
I want to incorporate the new taptic feedback available with the iPhone 7 into my apps, and I want to make sure my uses of it align properly with how iOS uses them at a system level. Without a device I can't test this.
Apple provides a document describing the different kinds of feedback: https://developer.apple.com/ios/human-interface-guidelines/interaction/feedback/ Namely "Notification", "Impact", or "Selection".
For instance, in Mail.app, when you slide a cell to archive it, it gives taptic feedback. Which of those three above (and their corresponding "variation") does Mail.app use? I'm guessing "Selection" but may be wrong.
Bonus points for pulling down Notification Center or Control Center, as well as any others you can provide for reference, but the gestures in Mail.app would be an awesome start.
You should check out this article, it gives you an overview how UIFeedbackGenerator works. https://www.hackingwithswift.com/example-code/uikit/how-to-generate-haptic-feedback-with-uifeedbackgenerator
Alternatively, you can create a demo project and check out which feedback is best suited for your needs.
Edit:
It's the selection feedback for Mail app. The notification center uses multiple feedbacks depending upon the sliding. If you do it slowly, it's impact heavy and how if you do it a bit slowly, it's impact light and if you just slide it down immediately, it produces no feedback.
I want to have in my app some nice slide navigationmanu just like in SWRevealViewController. My problem is that SWRevealViewController needs iOS 7.0 and ARC and in my project I have iOS 6.0 without ARC. Is there any way to use SWRevealViewController in my app or maybe there is any alternative to it?
You might want to take a look at ViewDeck https://github.com/Inferis/ViewDeck
It is compatible with iOS 6 and non-ARC.
I cannot tell about SWRevealViewController without ARC or iOS7 (thus I cannot directly answer your question), but I would put a lot of weight behind the following :
Over 80% of all iOS devices currently run iOS7 or greater. ARC has been available since iOS5, which is several years ago.
The mobile market is a quickly evolving one. Not upgrading will quickly lead you to a dark path where you'll end up fighting a losing battle. I understand that your project probably has limitations, but converting right now and keeping up with new technologies will save you a lot of trouble (for instance, trying to make a newer component work with your specific setup).
I would add, the same goes for AutoLayout. If you aren't using it already, you should start, NOW. Rumor has it the next iPhones will vary in size, and the legacy way of handling visuals cannot scale correctly (perhaps the whole reason AutoLayout was created is to prepare this change).
So in short, I wouldn't recommend adapting a new component to your old project, but rather updating your old project to make it modern. You'll end up saving a lot of time.
Hi I have been working on a blackberry app and developed about 90% of the app .But my client wants the app should work on blackberry touch also. So I just wanted to know what changes I will need to do to convert the same code to work on blackberry touch .Please help me I am new to Blackberry app development .
Just to confirm, we are talking about a Java application running on BB7 or earlier OS.
The short answer is, it depends.
If you have used standard RIM controls (buttons, ObjectChoiceField etc.) then these will work on the touch screen with no change. If you have used your own controls, for example an image button, then these might not work very well - for example the button might not be big enough to be hit easily with a fat finger.
The other problem is the virtual keyboard, it may appear at points when you do not want it to and not appear when you do. Not a problem on a lot of phones, but remember there are at least 2 non keyboard phones out there, so the Virtual keyboard is the only option for typing.
The best approach is work through each of your screens and try them in the Simulator. Zoom the Simulator so that it looks like the real device. And pretend you are using a finger, don't rely on the mouse because you can position the mouse very accurately.
I would raise new questions about specific Fields that you have problems with, rather than continue this with any issues you find.
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.