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
Related
I've created a core mechanic of my game and want to create a level editor for it. my game is not a tile-based one, so my needs are quite specific. Game is written using Swift and Cocos2d-swift, but i dont think i can figure something out with Sprite Builder.
What you can advice me? Can I for example create a level editor with c# and then use it from swift code?
And what data structure is the best?
I mean is it possible to serialize classes on desktop Swift application and then just load them on ios from file or I'll need to use json/xml?
It might be an old question but I ended up with using a .Net powered solution. I choosed as It has all controls that you need for creating a rich user interface and also, it has a lot of built-in and third party solutions for serializing levels in any way you want. And the c# syntax is very similar to the Swift one.
The only problem is that you might run windows to work with it.
My game in development also needed a non-tile level editor. A few months ago I took some time to make my choice.
Since my project still uses cocos2d 2.x, I don't use the whole new 3.x and SB system. After some investigation I found out that it would be too time consuming to adjust my whole project to the new system and adjusting SB to my needs, mainly because my game engine has been in development for quite some time and is close to finished. Further more, I couldn't find the right information to actually make it work for my game (it needed some odd level architecture I guess).
Finally, I didn't find any other good alternative so I decided to create my own level editor. In this way I had full control and I knew exactly how everything worked which was a huge advantage for me.
Right now my level editor has been finished for some time and works like a charm. I still think in my situation I made the right choice. Also because I learned a lot this way, building everything from the ground up. Having said that, for my next game I will probably go with the main stream and use SB from the start. Also for you I advice you to still check out SB and take some time for it before making an alternative choice...
I'll explain how I did mine. Disclaimer: it has some oddity's which only worked in my situation, but hopefully it helps a bit with choosing your own way to go, that's the goal I'm aiming at...
I used:
max/msp
Although it's developed to make music and audio based software, I used max/msp because it's very easy and fast for creating visual and interface based software as well.
More importend: I happened to be very experienced in it, which shortened the development time tremendously.
javascript
Inside the max/msp patch is a javascript file running. This file is like a bridge between the interface and the visual representation of the level being edited, and the database in which the level
is saved in. 70% of the editor development went into this file I think.
sqlite
All the data is written in a sqlite database. Again, this has been mainly the choice because it saved a great amount of development time in my case. I could have used xml files for instance, but my game was already using a sqlite database and because of this I felt comfortable using it, I had no experience in xml. Also all the code was already in place for a big part, which speeded up the whole proces a lot.
I'm very happy with the end result. It does everything I need, it's easy too use and since I made everything myself from the ground up I know exactly how every works.
Good luck with you choices.
I'm looking for a design guideline for large data entry in iPad application.
My application consist of more than 30 text field in one page that users have to input data in every each of them. My plan is to find the best way to have a user friendly app and easy to do the process as far as having a good design in the application.
Any suggestion?
Not sure how kosher this is to pimp my own stuff here (not like I make any $$ from it) but I've developed an open-source iOS project that handles quite nicely and easily just what you're looking for - user-friendly form/data entry.
https://github.com/mamaral/MAFormViewController
I have a big question about how newsstand works.
When you have to create a new magazine(issue), how do you do it?
I mean, Do I have to implement new code for each magazine (with new views and new view controllers) which doesn't look the same as the others and has interactive content? In this case, how do I add/upload/integrate them to my newsstand app which is already in the market?
In the case that It doesn't work in this way, How does it work?
Thank you very much in advance.
Your question really goes to the heart of how Apple has chosen to implement Newsstand. Basically, there are three possibilities for using Newsstand: use image/pdf content, use HTML5 content, and use the CoreText native API.
I take it from what you are saying that you would like to use the CoreText API. This is difficult to do in the Newsstand framework for the reason you suggest: you really are not supposed to upload a whole new app with each edition.
There are two possible solutions. The first is simply not to use Newsstand. Instead you can publish your magazine as an app, and simply upload a new app for each edition. This means you miss out on things such as subscriptions and the "double-listing" promotion of Newsstand, but you can make high-quality, native, custom interfaces.
The second is to do what I am in the process of doing right now, which is to develop something like an XML encoding that when loaded into your base app will generate the kind of interface you want.
At least that is my analysis so far. I would be so pleased to be told I'm wrong, really. But I do think this is one of those cases where Apple hasn't really thought through what they are offering. Maybe next year it will get better!
If you use the Baker framework you can download the interface elements (html, images) as "issues" and the code part (Baker framework) will stay the same.
To add a new issue you do the same as you do with downloading the PDFs using NKAssetDownload. If you're using Baker you will want to extract the whole "book" into the documents directory.
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.
I need to create a photo gallery for a website running IIS 4.0 or IIS 5.0 (im not sure which). It needs to display a low resolution version of the gallery to anyone, and it must show both the low and high resolution images for "priviledged" users. So I need access priviledges, photo albums and once the site is complete, the person I am doing this for needs to be able to upload their own images to the gallery. It also needs to have a minimal interface as it needs to be integrated into an existing website.
So I need some advice on this with the direction I should approach it.
Does anyone know if their is a customisable gallery out there that can do something like this, such as Coppermine or Jgallery or something. The alternative is to use a web framework like Ruby on Rails, CodeIgniter or Sproutcore (each which require learning a new language). The framework would be more work, but the existing galleries may not be customisable enough. The important bit is the user privileges in an admin panel.
I am relatively new to "web programming", although not new to normal/games programming. I have a few years experience with C/C++ OpenGL and Java. I have also read up on MVC etc, and did hello world with sproutcore, so I kinda get the idea. Although learning a framework is a much heavier investment.
What are your thoughts?
If you don't want to re-invent the wheel you could use Gallery2 (requirements here). It runs on IIS -- you'd just need PHP and a database. It's very configurable (including user accounts), has lots of plugins, and its open source if that's not enough. Also, the development and support communities are large and active.
you could always go the route of Dotnetnuke and then use Ventrian's Simple Gallery module (http://www.ventrian.com/Products/Modules/SimpleGallery/Demo.aspx)
Using DNN offers a ton of functionality, including the security you need, and it would save you from doing any web development.
If you are a bit more adventurous, try Smaltalk based Aida/Web and specially Aida/Scribo CMS (currently still in beta), which include Gallery so called scriblet as well. Scribo scriblets are otherwise web components which you can include directly into a text. You therefore add a gallery directly into a surronding text. See for instance a presentation as a Gallery for example.
I would recommend my own but... If it weren't for the low/high resolution thing with permissions I think it would fit the rest of your needs. I'm going to leave a link just in case you want to take a look at it:
nzFotolog
It's also open-source (although the license is not the best) and you can change it at will if you want. The code itself is clean and self-explanatory. The downside is that I haven't developed it for some time now :(
Having faced a similar dilemma myself I have to say that I found Gallery2 and Coppermine both far too all-encompassing and difficult to customise to the degree I would have wished. I ended up rolling my own using straight, procedural PHP with various bits of jQuery for the GUI fancy bits. At the same time I was able to bake in some e-commerce and data gathering for my wedding photography clients, ending up with something which exactly matched my needs. Certainly, the gallery aspects of this project were, for a complete programming (although not HTML) neophyte, the least challenging - it's exactly the sort of thing PHP is made for.
I'm now taking my first faltering steps with CodeIgniter for my next project (photoblogging software) and I can already see that the framework would make a gallery project very quick, simple and secure.
Flickr.com and their API may be suitable from what you described.
http://www.flickr.com/services/api/