Making a new format (ex ".rcb") [closed] - ios

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am wondering if it is possible to make a completely new format. Mac use a .text file for text and .mov for movies so is it possible to make a new format that i can put into a iOS application that it will use off and export off, for example the application pages exports a .pages file, and if so what is a good tutorial site or script that u can use.

A few thoughts:
File extensions
If this is just a file that your app uses internally, it doesn't matter too much what extension you use. Use whatever you want.
If you're going to be sharing files, however, you should ensure that you pick an extension that you're confident is unique. For example, it looks like RCB extension is used by Easy Resume Creator Pro (I don't know it, but that's what a quick google of that extension reports).
How to do it.
I'd simply advise you refer to How to Import and Export App Data on Ray Wenderlich's site, which describes how you can define a UTI for your app's data files. Also refer to this Stack Overflow answer.
How to store the information.
In terms of how to store the data in the file, you can obviously do whatever you want, but I'd encourage you to consider, if dealing with text data, using an established format (even if you're using your own custom extension). For example, if dealing with simple Cocoa objects like arrays or dictionaries of strings, numbers, dates, etc., I might suggest using a property lists (see Apple's Property List Programming Guide which writes data in an XML format.
Alternatively, if using your own NSObject subclasses, you can use a binary property list format as enabled by NSKeyedArchiver and NSKeyedUnarchiver which are discussed in Apple's Archives and Serializations Programming Guide.
There are lots of other formats that are open to you, but these two approaches take advantage of well established interfaces for reading and writing data and can be done with a minimum of effort
Alternatives to new file format.
Depending upon precisely what you're trying to do, if you're exchanging trivial amounts of information, a custom URL scheme might be sufficient. This bypasses the issue of dealing with custom file formats and enables a few other workflows.
Hopefully this is enough to let you start researching the different alternatives.

Related

Human annotation tool for corpora in NLP [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am trying to build my own training corpus for Named Entity Recognition, but I don't know if there is already an existing tool for this or if I have to implement one myself.
Basically, what I need to do is take a corpus and manually tag it word by word, which is pretty tedious, but it has to be done.
Can anyone tell me if there is already an existing one and where to get it?
I had a good experience working with BRAT.
GATE is also a very complex tool for annotating, steeper learning curve.
We had a nice experience using DataTurks . They provide nice intuitive UI which allows to add collaborator, insights into data, leaderboard for annotators and some other funky features.
https://dataturks.com
For online annotation of text or HTML corpus of relatively short documents I also recommend BRAT. You will have to go under the hood of the python web application if you want to do anything custom. It also failed to work for me on large HTML documents (100 or so pages).
I have also used stand-alone apps:
Protege + Knowtator: a bit cumbersome to setup / use, but it
works;
Gate: also cumbersome, and it somewhat works. Backup
your annotations at regular intervals as you might get
surprised by a stacktrace that also wiped or corrupted your annotated
corpus (which is just serialized Java objects).
If you are dealing with PDF documents, we built a web-based PDF Annotation Tool: NOTA. It accepts anything printed to PDF, including scans. We do commercial OCR on our end to recover text from images. There is a REST API to create color-coded annotation schemas and pre-populate documents with annotations, as well as a REST API for exporting formatted text and annotation offsets. There is also a JS API you can use to customize any annotation workflows, add metadata to annotations, etc. Relationships are not supported out of the box. Large documents, 200+ pages are supported. Email us and we can give you an API key to try it out. Details and documentation links can be found here. It is free for small research projects.
Here is a screenshot of what the annotations looks like :
I co-develop myself the web-based text annotation tool: tagtog.net
There is nothing to install, and you can define the type of entities you want to annotate. Additionally you can annotation relationships, document labels, and much more. You can upload your documents in many different formats, including PDF or markdown. You can annotate together with your team collaboratively. We have put great care in making the interface easy and beautiful. It looks like this:
You can start right away with a free account. Also I would be happy to help you with any doubt or issue you may have; just ping me or write us an email to the address shown on the website, tagtog.net.
Our annotation tool Prodigy is very scriptable, and is designed for active learning. It integrates especially well with our NLP library spaCy.
We've paid particular attention to the Named Entity Recogntion (NER) annotation workflows, as entity recognition can otherwise be very slow. I have a tutorial video on this:
https://www.youtube.com/watch?v=l4scwf8KeIA
There is this tool called, Dataturks is super simple to use, fully online NLP annotation tool, so that I even can easily push my teammates to complete datasets for our projects.
try TagEditor ,
It is a desktop application designed to annotate text for training with spaCy library.
You can tag Named Entities, Dependencies, Parts of speech, text categories
and print json file.
Example

Best option to store In-App Images in iOS [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
First I should confess that I am completely new to iOS programming and would like to get an answer for a question which I was googling all the day.
I would be having an app which will contain nearly about 500 images of png format with less size. How to store these images by categories inside the app? From what I learnt,
I can create a plist and map the images with strings (but not recommended by many if the data becomes huge)
creating a manual folder and storing the images (not sure how to do this..)
I have seen lots of codes on how to download and save the image from web or even from camera, but not sure what is the best way to store the in-app images which I have in hand in the app itself. Any sugggestions with sample code would be greatly helpful.
Are you downloading the images? Will these images ever change? Do you have a lot of metadata for each image (you mentioned storing them by categories).
While this is not the only way to implement it, I've had luck implementing things like this using a CoreData model that has an Image entity with category and filename as properties. You can store the images in the NSBundle or anywhere you like as long as they are in the same directory to make it easier on you. Then make sure each filename is unique and maps correctly to the CoreData entity.
This allows you to also at any time, allow more images to be sent down or even replace them. Once you download new images, you add new entities to your CoreData without you needing to update any plist or mapping. You also gain access to NSPredicates with the CoreData fetchRequest, which will allow you to query the CoreData for images that fall under 1 category or even several categories.
The downside is that it requires additional set-up, namely learning CoreData and implementing it into your project.
Edit:
For doing something right now and very basic, the answer is easy to implement. Add the folders into your directory and make sure they have the target/are getting in the bundle. From there, add a pList that for each category lists the filenames of every image you're interested in.
Then when in the app they click on a category, you pull the plist and get the list of names as either a dictionary/array. Then you load all the images.
The downside to this is that you have to manually update the plist for any new changes and send it down to the phone from a server.

guidelines from a pro for IOS 6 [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
i would like to know or maybe if someone can guide me what to do. for now im putting my mind on creating an app that gets the featured products on my website, using storyboard. where i click on products on my list in the tables view the it'll send me to next view to choose the product and when i click on the product and it'll go to another view where its details are written. i would know that it'll be done with parsing, or am i wrong.
its like, products --> products name list from web --> details
the interface and the tableview are already set, coding is just missing i just need to know where to begin.
Just a heads up, this question is far too broad for StackOverflow. You need to break this up and ask several smaller questions.
User Loads app, and it makes a request to your webserver asking for product list
(NSURLConnection)
Webserver receives request and sends encoded data back down. XML? JSON? Up to you.
(What software is running on your webserver? PHP? MySQL? Gather data and encode)
App Receives product data. Parse the encoding wrapper to get your object data.
(JSON or XML to NSDictionary, some good libraries available)
Populate data source with this data
Display data
If you have hundreds of products you'll probably need to reproduce this over and over, but that's up to you. If you only have a dozen or so it's probably easier to just send the whole chunk over on app startup.
Ace, if understand you correctly, the products itself should be fetched from the server. Then you can pick one or display the details. So, I would use a framework to connect and get the results from the server. There are things to consider: XML/JSON data parsing and mapping, Storing and caching the products, so you would be able to display them when there is no connections and updating with the latest changes. I am currently using RestKit which handles pretty much all of these things but for JSON. If you consider CoreData (database storage in iOS) you may need some additional help with retrieving the objects - MagicalRecord framework (on top of RestKit). It will handle things like findAll, findByAttribute:name: so you can get the objects you need. These frameworks are somewhat advanced, but on the other hand, they provide a sound ground for the UI stuff.
When you set up the backend integration and get your objects/collection of objects into the client, you can start populating the TableViews and displaying details.
One more thing to consider for a new project - CocoaPods. It is a very nice way to manage third-party libraries and frameworks. You just specify the libs you need and their versions (the good practice is to always specify the version, so the libs stay in sync) and it will fetch them and create a XCode workspace with them, so you don't have to worry about integrating them into the project. Both of the frameworks are there, just use
pods search <your_framework>
Good luck

App loading 600 static images locally, most optimal [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!

Ethics of storing signatures [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a piece of software that creates a contract and captures the client's signature via gif and applies it to the contract (and spits out a pdf). Now, we're storing the data from the contract but when it comes to the signature, I'm not sure if I should.
Store it:
Pros: If the pdf document is lost, I can reconstruct the document instantly and easily for whomever needs it (us or client). (checked with the lawyers, reconstructing the document from data is legal and applicable as long as no data is or has changed)
Cons: Although I will never do anything with the stored signature, I can't be certain that, if I ever leave the company, my coworkers or replacements will honor that.
Don't Store it:
Pros: Ethical high ground, there's no option for anyone now or in the future to use that image and do anything with it. It keeps everyone honest.
Cons: Now there is no way to reconstruct the original document if the pdf is lost - which is a good possibility.
Talk to a lawyer.
If it's grey enough an area, I'd vote for don't-store-it.
Lawyers are the most important people to talk to in this case.
But I'd still say don't store it.
If necessary, I'd suggest storing the contract in a format from which you CANNOT extract the original GIF. Such as taking a png file for the whole document, or some other solution.
However, if you are storing the whole document with the signature embedded (and not extractable) then you have your ability to resend the signature, and you have no reason to store the unattached GIFs.
Ultimately, having the unattached GIFs is just providing an enormous opening to getting sued.
Storing them that way also opens you up to problems relating to 'pasting the wrong GIF' into a contract.
I would say that having the gif files in a way that does not EXPLICITLY bind them to the ONE contract they apply to is VERY dangerous.
EDIT
After reading your post again I would say that there isn't a point in storing the GIFs or the PDFs. You should have a hard copy somewhere of the signed document (and if you are losing hard copies of contracts, then there are SERIOUS organizational issues) and after that, you don't need the signed version anymore, you just need to know the terms of the contract. So as long as you can reconstruct the terms for reading over, then I don't see why you'd need the literal signature again. If you need to prove they signed it, go back to the hard copy.
Do you need to keep the signature for anything else? If not I'd store it only for as long as is required to produce the PDF, as there is no reason to keep it around.
In New Zealand the collection of personal data is governed by the Privacy Act and as such one of its requirements is the data is only stored for the length of time required for the reason the data was collected.
The signature can still be extracted from the PDF. So whether you store the original GIF does not seem to make a difference, security wise.
How about this for thought:
If it was an electronic signature, you would probably not be able/allowed to store it at all. You could store the signature+document (i.e. the crypto-signed hash of the initial document) and verify it with the public key, but to store a lot of client's private keys to be able to re-sign documents.
Imagine some one breaking in to the database and stealing those private keys (gifs or RSA/DSA keys). That store would be very useful/profitable to a criminal organization.
Do you want to expose yourself to that?
I don't know, a GIF can be re-created by anybody with a copy of the document and a scanner...not storing you lose the benefit of having it, without any real security value being added....
I would get legal advice on some text to place near the signature in the final document. Maybe something like:
John Hancock http://rightzinger.com/LibraryofProgress/FoundingFathers/John_Hancock_signature.gif
(electronically added signature)

Resources