I am wondering if there is a way to reuse listbox items cells so you don't have to recreate the cell for every item individually?
this technique is used in iOS and as i've seen so far(by simple observasion, no tests were concluded), the performance in lists is much better in iOS then WP7 (on some-what equivalent hardware). Is this improvement due to the OS itself or is the UITableViewController(iOS) better handeled than the listbox(wp7) ?
Yes it is possible but you will have to look more into Silverlight(Xaml) Design.
You can define all rows in the list box to be completely identical with a little code,
Xaml will be the code behind for the design.
ListBox and Silverlight,
I would recommend reading the above page and maybe it will give you a better feel, i develop on both IOS and WP7 and i definitively prefer what the WP7 has to offer.
It just takes a bit of knowledge on both Xaml and The language of choice for the code behind.
Related
My iOS app is a mobile version of a management program I had developed for a company as a desktop application. So its main tasks are saving data in a database and retrieve them when needed with the option to edit them. So I guess that the GUI is mainly composed by forms to fill in and tables to show data. So I am asking you if you could link me some tutorials or give me some tips on how to realize them in a nice way but not too complex. I'd rather avoid simply creating a blank view controller and inserting labels and text fields without a minimum of criterion. I am very new to iOS and XCode and, as I have not too much time, I am asking directly your opinion instead of spending hours in looking for tutorials.
UPDATE!
I mean that I would like to get something similar, for a mobile iOS device, to the following screenshots (from the desktop application I mentioned above)
Seems that you need a grid control to do it.
You can develop your own, or use existing library.
I have very good work experience with Infragistic http://www.infragistics.com/products/ios/grids/grid-view-layouts, but maybe DataForm from Telerik will be better in your case http://www.telerik.com/ios-ui/dataform
There seems to be a lot of conflicting information out there. It might be that support has increased recently, or changes to adobe.com/air have made some information difficult to find - but I can't track down a definitive list of things to avoid.
I know that actionscript won't run in loaded SWFs, I know that some people say that filters and blendmodes and halo components won't work. I've also read many posts saying they will (at least that blendmodes will, and that halo will run, but slowly so still use spark)
I have a large amount of AS3 code to plan for upgrading to work on iOS, but at the moment I have no idea what things will break (or what things will break when those things have been fixed!)
Is there a list of unsupported APIs, or iOS dos and don'ts?
Thanks
:S
First, yes. Externally loaded SWF's will not run. You can however embed SWF's/SWC's into your project and include them inside of your package.
As far as Flex components, stay away from Halo. You should use Flex 4.6 and stick to components with mobile skins. I recommend downloading Tour de Flex http://www.adobe.com/devnet/flex/tourdeflex.html to get an idea of whats available.
As far as blend modes go, I'm not really sure. I haven't used them in mobile yet. However filters are supported but they are expensive. For drop shadows on rectangles there is something called RectangularDropShadow. This is actually a component and therefor less expensive. However it can only be used on rectangular groups.
You should have access all of the AIR API's. You will however be restricted when using some of File related classes since I don't believe you can leave your Appliaction Storage Directory.
One big performance tip I can give is to use AS3 over MXML whenever possible, ESPECIALLY when creating item renderers. Use BitmapImage over Image whenever possible, again especially in item renderers. Use cacheAsBitmap whenever you have images that don't change often. And stay away from any Flex component that doesn't have a mobile skin.
You may also want to read up on View and destruction policies.
http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tricks-pt1.html
This link also has some more performance tips
http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist.html
I was looking into creating iOS-apps (especially for the iPad) with the Adobe-Flex framework. It looks very promising to code apps this way.
Is it possible to create own controls/widgets? In the far future I might want to create my own kind of gantt-calender or whatever. Is something like this possible and are there any good tutorials/book out there?
Thanks in advance!
UPDATE: I want to create iOS Components that I can use in Flex. Controls, that are not aviable by default in Flex. Is that possible? By derivating or something?
UPDATE 2: In the meanwhile I found FlexLib to be useful. How hard is it to create stuff like this on your own? Especially for mobile devices. Are there any good tutorials, books, etc. out there?
Yes, you can create your own Controls in Flex. They are commonly called Components. I suggest you start by reading the Flex Docs on how to do so. There are also plenty of other resources out there. One is a screencast series that I created for The Flex Show. Here is episode 1.
You had asked:
How hard is it to create stuff like this on your own?
It depends on what the component wants to do. The commercial components we've built at www.flextras.com have taken from three to twelve months to build. Our Calendar is built from scratch, but most of the other components extend existing Flex Framework components.
The Flextras stuff are architected for reuse. A "single use" component for a specific app can be built in 1 hour [and up].
Once again, the purpose of a component will affect how long it takes to build.
#chiffre
Ok, maybe I am guessing wrong but "iOS controls" makes me think not to "flex controls".
Anyway with Flex 4.5.1 you can add any controls you want, the only thing that you must count (and this counts a lot) is performance.
Read especially about item renderers since scrolling list is not so fast on iOS and how you can make use of cacheAsBitmap.
Also keep in mind to always use light controls when needed if not extend base controls like UIComponent or Sprite and not Button if you just need a rectangle.
Here are some links
http://blogs.adobe.com/flashplayer/2011/06/adobe-air-2-7-now-available-ios-apps-4x-faster.html
http://www.adobe.com/devnet/flex/articles/mobile-development-flex-flashbuilder.
Say if I need to display a list with lots and lots of records, which control is better? Or shall I say, which control has a better scrolling experience?
I've seen a lot of people reporting issues on this LongListSelector, is it really too buggy to use?
Hope someone can shed some light on this for me. Thanks in adv.
Xin
If you don't need grouping, I wouldn't use the LongListSelector. The virtualization support is easier to use/manage with a regular ListBox.
And as of Mango, the ListBox performance issues are no longer a issue. You get smooth scrolling with both.
So I think you should stick to the ListBox.
The LongListSelector is used when you want to do more stuff with your list instead of just showing plain list items. LongListSelector supports grouping, which again supports easily jumping to another group. Both have visualization, so if you don´t need/want that, I would go for a simple ItemsControl and a scrollviewer(which is built in in the listbox and longlistselector).
I am working on BlackBerry user interface. But the BlackBerry UIs are less attractive compared to Android UI. I want to make my BlackBerry UI more attractive like in Android.
#Dave Markle is right, this is a fairly general question. Assuming that by 'attractive' you mean 'UI Controls that look better than the default' then you'll have to do a lot of custom control work. More an more in the BlackBerry industry it seems that leading applications are doing almost entirely custom UIs.
I won't touch on specifics of graphic design, that seems outside the scope of SO, but a good place to start is to get a graphics designer to put together some conceptual screens, and then as a developer your job will be to build controls to match that.
There are some tutorials on the net about how to get started with that. I've written a few - "BlackBerry UI - A simple custom field" is a good basic introduction on how to make a custom control.
And a correction to #Dave's comment - you can antialias text on the BlackBerry - though it's not well documented. For example, a 9 pt subpixel antialiased bold font, derived from the default system font:
Font.getDefault().derive(Font.BOLD, 9 Ui.UNITS_pt, Font.ANTIALIAS_SUBPIXEL, 0);
Well, after a couple of beers a lot of things look more attractive... ;-)
But seriously, I think you're going to run into some fundamental limitations with the platform you have. The iPhone, Pre, and (I guess?) the Android all have dedicated graphics hardware which can antialias text and perform complex animations with relative ease. Most blackberries don't.
I generally suggest to people that when they do a design, that they try to stay within the boundaries of the device they're designing for. For example, if you're writing an app for Windows XP, don't try to make it look like it might on a Mac. Stay with the style of the best-of-breed applications on the particular platform you're designing for. Maybe this answer isn't helpful, I don't know... But it was a pretty general question.