Until now I've coded my iOS applications using "pre-made" UI objects such as UItableViews, UIButtons and UIcollectionviews and it's been great.
But then I open instagram or other famous applications and I cannot recognise the UIobjects used in those applications as the ones I'm used to.
I make some examples: the shutter of instagram camera is something I've not seen before in pre-made objects, the "swipeable" snapchat user's cells have different behaviours in respect to the ones of a common UITableViewCell.
So my question in this case is : do developers use already made "UIObjects" and then they customise them, or they use different Libraries that allow you to create better objects?
I'm a novice in this field so probably this question doesn't have so much sense for a skilled developer.
The big companies make millions of dollars off of their single application and have dozens of iOS developers working on it. As a result, they can afford to expend resources in making their own custom UI elements.
If an element is popular enough, sometimes an individual developer or small group will duplicate the behavior of an element and distribute it for free to the rest of us. One source of custom UI elements is cocoapods.org
Related
We are creating an iOS app that does not look like any other app you would find in the app store.
My question is, am I allowed to create custom components such as header bars, tab bars, tables etc. for my app and not get rejected by Apple when publishing the app to the app store?
Months of thought and planning has gone into the UI and flow of the app, so the user experience would be superb, we're just concerned about how apple feels about custom apps/components like these?
Regards
There's nothing inherently wrong with creating an app that's got a completely different look and feel to everything else.
But what I would advise is that you try to use the built-in components as much as possible. In recent versions of iOS Apple have introduced a number of APIs to let you customise their look and feel significantly, and some of the most innovative UIs out there are simple table and collection views that have been hacked to pieces.
This is because Apple's built in components have logged many hundreds of thousands (if not millions) of hours of real-world testing and use, and are thus vastly more stable and field-tested than a totally custom component. Plus, they often have various built in features (such as a scroll view's bounce) that are hard to replicate on your own.
So definitely customise your interface as much as you like, but while you're doing it think about whether you can harness the built-in UIKit classes rather than totally re-inventing the wheel.
More and more custom controls appear for iOS every day. If it is so good as you say, Apple will be happy to accept it. Don't worry.
Also take a look at these cocoacontrols
As said before, Apple will not have a problem with that .. as long as you don't use any private APIs. If you are developing these components on your own, you will have to make sure that these will work in future releases (which is not necessarily a bad point) . This may be a problem with third party components, as they may not be continued (or supported in future releases).
Hello I am building forms over and over in iPhone and iPad apps:
Custom UITableViewCells for labels with input
Localization for labels, placeholder text and section headers
Validation that marks the cells red or something and does not allow "Submit" if form is incomplete
Clicking in the cell activates the editable text box
Next / previous buttons
Reliable across devices, orientations, iOS versions
I can't imagine I'm the only one doing this. Is there a mature framework or something that can drop in and use? Could you please comment on how you use this library with designs other than vanilla UITableViews with your own colors etc.?
Take a look at IBAForms - an open source project from from Itty Bitty Apps. I haven't used it yet myself, however I believe it does most of what you want, except for validation. Here is the github page: IBA Forms
It hasn't been maintained in a while, but if you're looking for a forms library - it's mature and works. At the very least, it could be the starting point for something you take further.
Update: There is also Chris Miles' EZForm library, which is very nice.
Update #2: Have also started checking out QuickDialog, which seems to be very popular.
Update #3: Nick Lockwood has created one called FXForms
Update #4: Martin Barreto has created one called XLForm
I don't know if this counts as an answer, but i use Sensible Cocoa - Sensible TableView (STV) for this purpose a lot. It's not a "forms" framework (on top of UITableView) as such, but it can be used for this purpose in a very flexible way. It still requires some coding to build a full-fledged form but the UITableView/UITableViewController boilerplate code is reduced to a minimum. Unfortunately the developers bumped the price tag quite high with version 3.0, so i'm actually looking for a STV replacement right now. (I'd stick with STV if it wasn't for the price!)
I don't know of anything that combines all those features, but I recently open-sourced my validation library PMValidation on github, which I used developing the iPhone app Imprints. PMValidation comes with many basic types suitable for validating forms, and in fact that's what I originally built it for.
Using the PMValidationManager class you can easily listen to UITextViews or UITextFields, and update whatever graphical widgets you want via notifications. It's very modular and easily extendable, should you have more unique needs. It's under the MIT license.
I have a pretty much standard UITableView, but I would like to change it to look like what would be considered a normal table outside iOS development -- make it have more columns (but just one row) and make the cells square-shaped.
I thought about making more tables (one for every cell) and then placing them next to each other, but that wouldn't be so convenient.
Is there maybe a simple way to make cells go on the right of the one before instead of going below?
Use some third-party classes that allows you to have "Grid Views".
One is my OHGridView class, another is NRGridView, and there are many more. If your app needs to be compatible with iOS4 and/or iOS5, using a third party class (or building one yourself) is the only option.
Under iOS6, there will be some other stuff that allow you to do that directly (iOS6 still under NDA so we can't talk about it publicly yet, but go read the API Diff files in the developer.apple.com website if you have access to them). So if your app is intended to be compatible only starting iOS6+ and you don't need support for iOS5, this could be the solution and you should go read about it if you have a developer account with access to the iPs6 SDK.
What you're looking for us UICollectionView.
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'm working on the requirements & specifications for a new iOS app intended for use by certain professionals working "in the field". All day long for weeks on end, these folks have a sizable reporting burden to their superiors using standardized forms that track all different kinds of information. Traditionally, those forms are in PDF, and are simply printed and filled out in ink and then shared with the dozens to hundreds of others working the same operation. Sometimes they'll use a PDF with form fields so the data can be typed and then printed as part of the form. Either way, given their workflow, time and stress pressures, and other factors, it's not a very productive way to get the standardized reporting forms done.
The app we're spec'ing would offer an iOS (and Android, if possible -- but secondary or even tertiary requirement at this point) user interface for tracking the data they enter in the field, organizing it in a logical manner for each individual user, and with the press of a button, take all that data and automatically create a PDF file of it using the standardized form.
Of course, the forms are STRICTLY and rigidly standardized in this industry, and any deviation in format, structure, or presentation is simply not tolerable.
So I was approaching the project by thinking the app would maintain an internal repository of the original standardized forms from the accrediting organization, with each possible data area defined as a field. The app would:
open the necessary PDF form for the task at hand;
parse its dictionary to identity the specific data fields;
for every single field, identify the relevant data from the iOS app's own user interface and data tables, and assign that data to the corresponding field from the PDF/dictionary
export the PDF to a NEW PDF file, which the app would either email or store through iCloud, Dropbox, or some other form of file sharing.
The catch with #4 is that that PDF file must remain editable by standard PDF applications on Windows and Mac (Acrobat, Preview, etc.), so all the fields need to remain. And the PDF should be viewable just the same on either Windows or Mac.
Now, at NO time will the PDF (neither the original nor the exported final document) EVER need to be displayed inside the iOS app, nor would it make much sense to be able to do so.
I don't know if any of this is possible. This is our first iOS project, and we've been leaning towards building the app using Moai or Corona or some other framework to save development time and make porting across platforms easier. That said, if it cannot be done using Lua and one of these frameworks (I remain skeptical...they seem HIGHLY geared towards games), we're not opposed to doing it directly in Objective C and building an Android version some time down the road.
But either way, I'm at a loss in assessing whether this is even a practical undertaking. Our requirements are clear, and frankly if this can't be done, the project won't be pursued any further. But I could definitely use some help from you folks in identifying what my options are, whether I can do it in Lua, and what SDK(s) would be most useful in accomplishing this.
Based on what you've said, it seems that there is little reason to do the PDF-based part of the work on the mobile device itself since:
you don't need to display it on the ipad
you plan to email it or store it in the cloud
if you write this for iOS you will have to write again for Android as you've mentioned
Can you simplify the mobile part of your requirement by focusing on the data-collection and validation, then firing off to a server to do the document production? That will give you a lot more flexibility in the tools that you can use to merge the data into PDF docs. If so you could look at creating PDFs or populating the fields from code using something like iText (C# or Java). If you don't want to build your own back end server you could try something like Docmosis Cloud - but that might not allow you to get your precise layouts.
Certainly the catch you mentioned - needing to keep the PDFs editable with their fields is a significant gotcha in all cases. If you could convince the stakeholders that it is better to generate the final documents from your system (generate draft, review, update data, generate again etc) - rather than generating editable documents that you then lose control and tracability over, then you will be miles ahead.
Hope that helps.
Did you consider just generating a new pdf using an image of the form as the background to the pdf and just writing the user's data into the required areas over the form image. Would reduce the complexity of trying to parse the original form PDFs.
That's a point of worthwhile discussion, but one we don't have an ideal answer on. I tend to think of that as the almost perfect scenario -- it'd be considerably easier to develop. There are two key issues with this approach that have made us table it except as a very last resort:
The users of this product would be working in the field. That field could be quite literally anywhere--the streets of Manhattan, a disaster-stricken area with infrastructure that's been severely damaged or even destroyed, or the most war-ravaged third world country. If it were the streets of, say, Manhattan, there's no problem--their iOS or Android device will have 3G or Wi-Fi access just about anywhere they go. In the latter two scenarios (which are arguably more common in this industry), that connectivity may be very limited. The concern is whether the end user's ability to be productive or to see and share data with their colleagues will be too greatly restricted if they don't have a decent signal. To be fair though, even today they often aren't even using mobile devices, forcing them to go back to a headquarters type location or use radios to share information, effectively negating my point here. But if we're not going to significantly increase their productivity in the field, it just gives us pause to think through whether or not we have enough of a value proposition to ask them to fairly significantly change their methods of doing things.
To your latter point, no there's no convincing the stakeholders that this new system is the better approach. Even if there were, it would take years to do so. These forms are a part of a well-defined, decades-old standard used by literally thousands of organizations.