I have a lot of problems getting regular expressions working for my simple Cocoa application. I know that many people use RegexpKit Lite, but because it has an undocumented API call (to use the ICU library), I am pretty sure my app would get rejected when submitted to the Mac App Store (I know others have been rejected for using ICU in the iOS App Store).
My next step was to integrate with the full RegExpKit framework. While this works without issue in my application, it doesn't work in my unit tests. I have tried a lot of steps here - but, I still keep getting 'library not loaded' for the framework, even though there is a copy files build phase that puts the framework in the correct place. In addition, I spent quite a bit of time debugging another issue with the RegExpKit framework (dealing with the restrict qualifiers within the framework). Long story short - I don't think the RegexpKit framework is a good choice for me.
In reality, I just need a simple solution for regular expressions (speed isn't a primary concern as this will be used sparingly) that can be used within my unit tests.
Ideas?
[Edited post-NDA]
One option is to wait for Lion and then require it. Then you can use NSRegularExpression.
Related
I am using macOS High Sierra (beta) and xCode 9 (beta) and trying to work with localization. Anytime I try to import a localized .xliff I get an error that states: Couldn't communicate with a helper application. Try your operation again. If that fails, quit and relaunch the application and try again.
I have done everything I can think of. Any thoughts?
Localization using Apple's provided tools tends to go wrong much more often than it goes right. As far as my applications are concerned, I don't use these tools at all. That goes for any project where I'm using anything more complicated than the default localization function with default parameters:
NSLocalizedString("this is a key but also a string I guess")
Trying to do anything even slightly more cohesive:
NSLocalizedString("this_is_a_key", value: "This is a string", comment: "This tells the translator useful stuff")
ends up breaking the genstrings program and creating a whole other mess. I've taken to manually updating string resource files and using a third party or in-house script to generate other files (any .strings files for example). It may add a bit of arguably unnecessary human touch to the string generation process, though I don't find this to be problematic since it increases visibility of how strings work between the resource and application code.
Can anyone help me in understanding these question : What is the advantage of using Alamofire over NSURLSession/ NSURLConnection?
What are the differences between NSURLSession and NSURLConnection?
NSURLConnection is Apple's old API for doing networking (e.g. making HTTP requests and receiving responces), while NSURLSession is their new one. The latter one is higher level and is generally much easier and involves less boilerplate code to use for most application developers - there's basically no reason to use the former except in legacy code that you don't want to update.
A bit of history: Before NSURLSession came out, a third party library, AFNetworking, became the de facto standard for doing networking in Objective C, as it provided an easier and more convenient API than NSURLConnection (which it was a wrapper around - I think these days it wraps NSURLSession instead). The same developer later made a similar library for Swift, called AlamoFire in order to fully take advantage of "the Swift way of doing things" (instead of just adding Swift bindings to AFNetworking). Around the same time NSURLSession came out and it seemed pretty obvious that Apple had been inspired by AFNetworking and wanted to make their new networking API just as convenient to work with - by and large I think they succeded. What this means is that while previously, using AFNetworking instead of NSURLConnection was the only sane choice for most developers, today the advantages of using AFNetworking or AlamoFire over NSURLSession are much smaller, and for most developers starting up new projects I'd recommend to just start by using NSURLSession and only look into AlamoFire if they feel that they run into some limitation or inconvenience that is big enough to justify adding another dependency.
Alamofire is built on top of NSURLSession, and is less lines of code to do REST interactions with (POST/GET/PUT/etc). It will get you "90%" of the way, but if you need to do super specialized network calls, you will need to use NSURLSession.
Ex: Simple Alamofire call that gets JSON
Alamofire.request(.GET, "https://www.google.com/",encoding: .JSON).responseJSON {response in
if(response.result.error == nil){
print(response.data)
}else{
print("Network Error")
}
}
NSURLConnection is now deprecated, and NSURLSession is the new standard.
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/UsingNSURLSession.html
First let me answer the difference between NSURLSession and NSURLConnection
NSURLConnection : if we have an open connection with NSURLConnection and let's say you close your app, then everything we received or sent is lost
NSURLSession: Here this case is handled with the help of a app delegate method
application:handleEventsForBackgroundURLSession:completionHandler
Here's a link i found which might be useful in explaining the difference better between the two
let's go to your initial question of advantage of Alamofire over the default framework class, and am just sharing my experience on what I did so far so get ready as it's a long read.
For me the thumb rule is never bypass the framework unless you have a strong reason for doing so irrespective of what technology you are using.
Reason behind that is I have used third party library in the past and that did not end well with the latest updates of iOS and let's say if you have a paid app and your third party library stops working then your client's app will loose it's value and will end up having negative comments on the app store.
I advice before using any third party library please make sure you make a check of the given questions
what's the frequency of updates?
how many open bugs are open?
Is it really worth using it or you can leverage the framework classes?
What's the license of this library?
Coming back to the question, I used Alamofire in one project which was just making get, post and put calls had some offline sync features.
Now thinking about it i could have made my own class with URLSessions and handled response accordingly there was no need to use Alamofire as i was not doing anything special here.
I believe this was all achievable by the default framework than using a third party but i used it anyway. Why did i use it don't know maybe i was curious but a lesson learned here was i could have achieved the same thing by using framework classes, if let's say the library stops working I would have no clue as to why it did and would have to rely on a fix from the care-taker/author of that library which may take a month, week, day who knows
Once i used a library for a feature i wanted but that same feature had an open defect for it and it was never updated so i ended up making my own custom one and till today it's working fine so do go through all the open defects section to avoid unplanned surprises.
Also as mentioned in the above answer use third party components only and only when you run into limitations with the default framework and even before you do please do check when was the last time this library was updated, what license it has and how many open defects are there.
For Swift 3.0 and above, Alamofire is best because it is well Optimized and also reusable and it has also many Build in features.Alamofire calls for a similar approach in that one creates a router by conforming to a protocol, URLRequestConvertible. Under the hood, Alamofire calls for a singleton pattern that’s built on top of an NSURLSessionConfiguration.
The advantage is that there is a higher level of abstraction, so you can write less lines of code. However, there is still no official support for Codable. Updating Swift version can come with its downsides, but I think this should improve with ABI stability in Swift 5. Also, you have got to be mindful of security vulnerabilities.
Back in the Objective C and NSURLConnection days then libraries like AFNetworking made a lot of sense, but with Swift, Codable, and URLSession, then I think there is less of a case to be made for using Alamofire.
The question is quite simple:
Can we use JavaFX as a thin client running on a browser while a java server does most of the work?
IE: cretate the UI and it's controllers with JavaFX and have the bussiness/database connection/etc part run on a server?
Even if possible, would it be a complicated turnaround?
Based on the information you've provided, I wouldn't necessarily say that JavaFX is a good fit, but on the other hand I would not worry about the load times. My rationale is: The bad thing about JavaFX is that you have an additional tech requirement for your clients (JVM) and require some form of installation (even if it is just an applet). Those won't be a factor for HTML5. JavaFX has benefits over HTML5 if one of these cases is true:
1) You have complex controls and/or a lot of user interaction with the UI
2) You need your application to be really flashy, e.g. by incorporating animations
3) You have a complex business logic that you would like to execute on the client (e.g. because you had a previous implementation as a rich client)
'Some tables and simple controls' don't really fit here.
The reason why I wouldn't worry too much about the download time is that most users of an enterprise application will be using your app a lot from few different machines, thus caching should deal with that problem (plus an FX app is not going to be that large).
There is an interesting article on the topic to be found here: http://www.oracle.com/technetwork/articles/java/casa-1919152.html . Since it is coming directly from Oracle, you should of course take it with a pinch of salt, but I for one do agree with the general notion. The article also outlines some (subjective) experiences when switching to JavaFX.
If it's an enterprise app, and you already know that your users will have java installed on their clients, javafx is a good solution. If not, the downloading of the javafx jar can be quite a buzz kill the first time an app is run, as it's quite (understandably) large. I'm using it for enterprise apps, and the web start functionality works well.
And don't forget, if you're using jdk 7, there is a javafx packager which will create a single file installer/run-time for your app. I can't provide a lot of detail for that as I haven't bothered with it yet.
We have a shoebox-style application that we want to make a first-class citizen in Lion. This means integrating Auto-Save & Versions among other things. Currently we don’t have a document-centric model and we just use a plain Core Data stack.
UIPersistentDocument provides a really easy way to integrate both Auto-Save & Versions and I see two options we could choose from to integrate with the new APIs:
“Abuse” NSPersistentDocument for our shoebox-style application. Technically it would be a document-based application, but the user interface would still be the same iPhoto-like library. This makes conceptually not a lot of sense, but we would get a lot of functionality for free.
Keep the current plain Core Data stack and implement Auto-Save & Versions manually.
I heard contradicting opinions from Apple representatives about the approach we should take and it would be great to clarify things before we start our implementation. While I think that 1. shouldn’t be used it’s also very tempting, because we get a lot for free. I couldn’t even find sufficient documentation on manually implementing Auto-Save & Versions in a Core Data application.
I would really tend to use 1. but I see some problems:
I’m worried about file-system-level conflicts when using versions and only one database-file. I couldn’t find any documentation regarding this topic.
I’m worried about performance issues in Versions when browsing through “space”.
We can’t enforce only one instance of the open database, since Versions has to open several instances. I’m worried about side-effects and concurrency issues.
Conceptually it looks like a hack and I don’t like hacks.
If we would only want to integrate iCloud sync I definitely wouldn’t think about using a document-centric model for our application, because Core Data supports it directly. I’m mostly worried about the developer overhead we would have if we would stick to our current non-document based paradigm.
Do you have any advice or ideas how shoebox applications should be integrated in the new Lion world?
I'm afraid you're forced into using the first option. Versions is implemented inside NSDocumentController *sic* and so you will have to use some kind of NSDocument to get anything out of versions. I think you also have to add your App's Window in a NSWindowController to that document in order to get the nice little popup menu at the top. The problem is that versions is more or less a completely opaque feature...
But there's a question you gotta answer yourself: What portions of your app would you want to put into version? Does it really make sense to have everything in a single file when it comes to restoring data? Version restore (other than copy&paste) happens on the file-system level. And thus, does it really make sense to always have everything restored at once? If your answer is no, you probably even have to slit up you model into multiple smaller files...
Don't expect improvement here until the next major release. That's what I guessed from the engineers comments...
I have a simple problem, I will be straighforward.
Suppose I have a third-party cocoa application running that has a chat box inside. Well, I need to capture the text inside that chat-box in real time from another application and write a logfile in real time with that information.
I am sure there is a way, I just don't know where to start. I have experience with cocoa and objective C, I have some apps in the iphone app store.
Thank you very much
Unless the app is suitably scriptable (e.g. AppleScript) or has some kind of external API then you're not going to be able to do this.
In short: Contact the developer of the application, but don't get your hopes up.
Unfortunately, in this day and age of protected memory and whatnot, we more or less have to be content with what the applications give us to work with.
However: You are not entirely without recourse. Using F-Script you might be able to attach to the process and cause some controller or other to emit notifications that you can capture and log.
Edit: If, as appears to be the case, it's a Carbon application, you are well and truly hosed:
F-script and similar is unlikely to be possible.
Even if it is, trying injection on a Carbon app, that is to say, a C++ app, is likely to be an exercise in futility and disappointment, if not completely impossible.
Seeing as how Carbon is deprecated (and how!), the application is unlikely to be updated with a proper API for that sort of thing.
All of the above.
Reedit: One tiny little aber; it is possible, although unlikely, that you can achieve something using Interface Scripting, but again; I wouldn't get my hopes up.