|
eschaton posted:
Close enough I'd call it probably. My code might be causing selection to work in reverse. Which causes the last selection to get the text edit events whereas in textedit, under multi selection it looks like the top most selection(cursor position) gets the events.
|
#
?
Jun 15, 2016 07:15
|
|
|
|
| # ? Jun 8, 2024 00:36 |
|
|
Anyone use the Dropbox API in their app? I have an idea for sharing, but I don't know if it's a good one. Background: my app plays music files (.pd, basically a text file) and references associated resources (.aif, .wav). All editing is done on the desktop, and I need a good way to get those files onto the mobile device for playback (iTunes File Sharing is not a good way). Idea: what if the user could chuck their files into a Dropbox folder, and just sync that folder on the mobile device? Question: can users share links to Dropbox folders? I'm really hoping that if another user was like "check out my stuff!" they could just send a link, and my app could just link to that user's folder, and it would be a simple sharing solution.
|
|
#
?
Jun 15, 2016 13:57
|
|
|
Another idea if Dropbox doesn't pan out is running a lil web server and getting people to browse to it and upload the stuff that way. I'd try Dropbox first though, that sounds ideal.
|
|
#
?
Jun 15, 2016 17:32
|
|
|
eschaton posted:That's a bit of a creative way to reframe "we can't talk about future plans…" Because really, we can't talk about the future. I'll stop by the lab today, I have some ideas.
|
|
#
?
Jun 15, 2016 17:46
|
|
|
eschaton posted:I'd like to be there if someone organizes it, though I'm now committed to 12-6pm lab shifts every day. (Well, not til 6 on Thursday, my talk is at 5…) So I'd prefer evening, but I wouldn't want that to be a holdup for anyone else. Yeah I'd be in for an evening meetup (at a nearby bar or something? I don't really know SF)
|
|
#
?
Jun 15, 2016 19:26
|
|
|
This evening I have dinner plans but could do something after that. Tomorrow evening I kind of have to be at http://www.meetup.com/realm-sf/events/231366223/, but Friday I could do dinner/bar time/whatever.
|
|
#
?
Jun 15, 2016 19:58
|
|
|
lord funk posted:Anyone use the Dropbox API in their app? I have an idea for sharing, but I don't know if it's a good one. Should be able to. I can right click on a subfolder of my Dropbox folder and get a share option. And with the universal clipboard on iOS X (  ) and macOS 10.12, users could copy the link on their Mac and then paste it into your app on iOS.Depending on how the universal clipboard API works, you could even monitor it for Dropbox links (or check when the user switches to your app), make sure it's a link to your app's project file type, then ask if they want to download it. That way all a user would have to do is copy the link to the clipboard on their Mac and it would automagically show up in your app, without having to do something gross like have a text field for them to paste it into. Also, the Dropbox API was pretty easy to set up and use the last time I worked with it in an app. They provide a native wrapper library for iOS.
|
|
#
?
Jun 15, 2016 19:58
|
|
|
Yeah it seems like Dropbox API v1 does allow you to list shared folder contents, but v2 removed that feature. While I'm shopping around: would Google Drive work? Anyone using that?
|
|
#
?
Jun 15, 2016 20:23
|
|
|
sarehu posted:Where does NSUserDefaults stuff get stored when doing development? It's not in, like, locations that googling would suggest. I can find a file in ~/Library/Preferences and delete it, but then the preferences are loaded from somewhere else the next time I start the app. Late but this popped up in recent change notes. quote:NSUserDefaults detects folder deletion
|
|
#
?
Jun 15, 2016 20:44
|
|
|
eschaton posted:That's a bit of a creative way to reframe "we can't talk about future plans…" Because really, we can't talk about the future. Great job tonight! I didn't come say hi because I didn't know which presenter you were and I'm terrified of Goons irl. But definitely excited to see what is made with what you guys have done. 
|
|
#
?
Jun 17, 2016 01:52
|
|
|
I'm having a tough time breaking into Swift. I just tried to utilize it in a new project, but it turns out I really couldn't, as I needed to import some of my old code into it, and all of that code is in C and C++. Is it really worth it to rewrite a sound chip emulator, a retro MIDI processor, and a MIDI file parser (including multiple obscure formats) in Swift, just so I can avoid having to write C++ to C bridges and compile them into their own frameworks for everything, just so I have some code that is no longer portable? I mean, I was doing sort of okay with the bridging, until I got to Core Audio output, where I stupidly tried to import a giant "AudioKit" thing, which in turn wanted a pile of Swift/Obj-C dylib files that didn't materialize in my build products for some reason, and the only posted solution on Stack Overflow was to Clean and Rebuild, which did Jack and poo poo. Then I remembered that I had a 250 line Core Audio output framework that worked with callback functions to feed it sample data in the requested format and sample rate, in C++. After I already gave up and moved on to writing my app in Objective C, using mostly copy pasted code and XIB resources from MIKMIDI, with zero storyboard use to boot. Which my happy code slave / SO has pared down / massacred to a tiny resemblance of its original form. I still want to get him to learn C/C++/Obj-C, but maybe I can at least get him to learn Swift, and help me to learn a purpose for it as well.
|
|
#
?
Jun 17, 2016 03:42
|
|
|
In my experience, if you are adding Swift to a project with existing C/ObjC targets, you'll have to add a build phase to manually copy /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libswiftX.dylib into ${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH} (@rpath should already be looking in the right place) because telling it 'this project contains embedded Swift code' will have it use instantaneous stellar alignment to determine if it will copy 0, 1, or more of the runtime dylibs over from build to build, regardless of framework/module-related build settings.
|
|
#
?
Jun 17, 2016 04:21
|
|
|
Doh004 posted:Great job tonight! I didn't come say hi because I didn't know which presenter you were and I'm terrified of Goons irl. But definitely excited to see what is made with what you guys have done. Thank you! I was the guy who talked about extensions. 
|
|
#
?
Jun 17, 2016 10:02
|
|
|
I'm having issues with custom frameworks. I'm attempting to bring in SVGKit and following the instructions here - https://github.com/SVGKit/SVGKit. I can get it to work for a particular build type ( either iOS device or emulator ) but to do so I first have to rebuild the framework for the particular target, remove the existing framework and then re-drag in the new one. If I don't do this I get the followingcode:Edit: It looks like SVGKit includes a script to make a fat binary ( from here - http://stackoverflow.com/questions/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4 ) but for whatever reason it still fails when I attempt to build my project. hmmm... fankey fucked around with this message at 17:24 on Jun 17, 2016 |
|
#
?
Jun 17, 2016 16:21
|
|
|
fankey posted:I'm having issues with custom frameworks. I'm attempting to bring in SVGKit and following the instructions here - https://github.com/SVGKit/SVGKit. I can get it to work for a particular build type ( either iOS device or emulator ) but to do so I first have to rebuild the framework for the particular target, remove the existing framework and then re-drag in the new one. If I don't do this I get the following Yeah, you need a fat binary if you want just one .framework After you build the fat binary, open Terminal.app, cd to the directory that the binary inside the .framework is in, then type "file [binary file name]" and it should show you all architectures included in that binary. The error message says it's missing code for i386, so that means the 32-bit simulator, so make sure an i386 section is in your fat binary. Or run the 64-bit simulator, if the framework has x86-64 but not i386. Another way to do things would be to just drag the library's Xcode project into your Xcode project, then in the build settings set its static library target as a dependency and the static library output as a library to link against. Xcode will then always build the static lib for whatever architecture you're trying to test on, and build it for all of them when you do your distribution build. When I'm back at my computer I'll look at that lib and see if I can figure out why it isn't getting built as a fat binary.
|
|
#
?
Jun 17, 2016 19:14
|
|
|
Doc Block posted:Yeah, you need a fat binary if you want just one .framework Looks like the framework I built only includes ARM code:fankey fucked around with this message at 20:18 on Jun 17, 2016 |
|
#
?
Jun 17, 2016 20:14
|
|
|
The static library target runs a script that uses lipo to combine the device and simulator binaries, whereas the framework target does not. If you build the framework for the simulator then it will only have the fat binary for the simulator, and vice versa if you build it for a device.
Doc Block fucked around with this message at 20:57 on Jun 17, 2016 |
|
#
?
Jun 17, 2016 20:53
|
|
|
fankey posted:I can't figure out how to force Xcode to build the Framework with both ARM and x86 together. I can get it to build a universal static library but not the framework. Sorry I haven't responded earlier, it's been a very busy week as you might imagine. The short answer here is that you can't force Xcode to do this because combining architectures for different platforms in the same Mach-O isn't supported. The lipo tool won't prevent you from doing this yourself because it's intended to be a low-level tool with sharp edges, rather than something you should use as part of everyday development yourself. If you can trick Xcode into building a static library for multiple platforms that's actually a bug on Xcode's part. One reason for this is that Mach-O doesn't really track both platform and architecture, it just tracks architecture — and as we all know, i386 means different things on different platforms (for just one example), and devices & simulators are themselves different platforms. If you're using pre-built frameworks for different platforms, I'd recommend having them in sub folders of whatever the SDK folder is that are named for the platform identifier. E.g. FooSDK/iphoneos/Foo.framework and FooSDK/iphonesimulator/Foo.framework and so on. Since Xcode will search for the framework by name at link time, you can just then have /path/to/FooSDK/$(PLATFORM_NAME) be the value that's in your Framework Search Paths build setting. If you're building the framework yourself, just having the project that builds it be in the same workspace as your app project should be sufficient to ensure that when you're building for iOS everything goes into the Debug-iphoneos directory and when you're building for iOS Simulator goes into the Debug-iphonesimulator directory and so on, based on the run destination you've selected in Xcode's toolbar. If that's not happening my first suspicion would be that something is trying to override BUILT_PRODUCTS_DIR or another setting like it, and not accurately replicating how Xcode varies it per platform.
|
|
#
?
Jun 17, 2016 21:17
|
|
|
So I'm finally using Swift (new job yay) and I came across this today: Sent it to my friend who was attending a Swift lab at WWDC and he said this: quote:I see they still haven't fixed that What the gently caress. I mean the refactor tool can barely refactor Objective-C, but still.
|
|
#
?
Jun 17, 2016 21:39
|
|
|
eschaton posted:Sorry I haven't responded earlier, it's been a very busy week as you might imagine. For that particular framework (SVGKit), the developers' instructions are to open the framework's Xcode project, build the framework target, then copy/paste the framework into your project. Which doesn't work if you build it for the device but then try to run your project on the simulator, and vice versa. While it's obviously a bad idea to try having both macOS and iOS simulator code in the same fat binary, I think it should be entirely possible (and supported) to have both iOS and iOS simulator binaries in the same fat binary. Doc Block fucked around with this message at 22:03 on Jun 17, 2016 |
|
#
?
Jun 17, 2016 21:59
|
|
|
kuroshi posted:I'm having a tough time breaking into Swift. I just tried to utilize it in a new project, but it turns out I really couldn't, as I needed to import some of my old code into it, and all of that code is in C and C++. Audio stuff is traditionally done in c/c++ on all platforms because of how memory allocation is more predictable and you can be sure there's no locks. I recommend having just the UI and new non-audio related code in Swift.
|
|
#
?
Jun 17, 2016 22:00
|
|
|
I think what he's referring to is that Swift can't interoperate with C++. So you can't link to a C++ library from Swift code, etc. Hence the part about having to write a C++ to C bridge, so that he could call the audio code from his UI written in Swift (since Swift can interoperate with C).
|
|
#
?
Jun 17, 2016 22:02
|
|
|
status posted:So I'm finally using Swift (new job yay) and I came across this today: If it makes you feel any better, it can't refactor Objective-C++ either.
|
|
#
?
Jun 17, 2016 22:03
|
|
|
Doc Block posted:If it makes you feel any better, it can't refactor Objective-C++ either. Ahh, I remember that frustration from working on Cedar.
|
|
#
?
Jun 17, 2016 22:10
|
|
|
eschaton posted:If you're using pre-built frameworks for different platforms, I'd recommend having them in sub folders of whatever the SDK folder is that are named for the platform identifier. E.g. FooSDK/iphoneos/Foo.framework and FooSDK/iphonesimulator/Foo.framework and so on. Since Xcode will search for the framework by name at link time, you can just then have /path/to/FooSDK/$(PLATFORM_NAME) be the value that's in your Framework Search Paths build setting. Thanks for the info. I got the build working using the $(PLATFORM_NAME) scheme. Since the library is dynamic I'm having issues with running. It seems like the 'Embedded Binaries' is ignoring the $(PLATFORM_NAME) since it's complaining that no matching architecture is found. When I add the Framework to the Embedded Binaries list it shows the path to a specific Framework ( in this case the one that works ) in italics and I can't see a way to use PLATFORM_NAME as an indirection. I'd try adding everything to the same workspace but my project has somehow been broken in a way that makes it not possible to add it to a workspace - it just shows up as a single item without all the supporting stuff. This is probably due to me attempting to de-workspace when I was also de-cocoapodding since that was causing more problems than it was solving. One other question - I used Carthage to build a different library ( CocoaAsyncSocket ) and it's working without any issues and shows all architectures in one Framework file code:fankey fucked around with this message at 23:02 on Jun 17, 2016 |
|
#
?
Jun 17, 2016 22:52
|
|
|
Check the PM I sent you. I don't see a problem with having different architectures for the "same" platform in one fat binary (iOS device and iOS simulator). On the other hand, it's kind of a waste of space on the user's device. Obviously, you can't have separate x86/64 slices for both the iOS simulator and macOS in the same binary, but since iOS and macOS apps/frameworks are built with different targets and thus get different binaries it shouldn't matter most of the time. If you don't have PMs, or just for the record, here's how I got SVGKit to work on both the simulator and device: 1)Drag the SVGKit-iOS.xcodeproj into Xcode, adding it as a sub-project of your app's project. 2)In your project settings' Build Phases tab, add "SVGKitFramework-iOS (SVGKit-IOS)" in the Target Dependencies section (click the + to add it) 3)Add SVGKit.framework in the Link Binary With Libraries section 4)In Finder, open the SVGKit folder, then "3rd-party-frameworks", then "CocoaLumberjack-2.0.0" folders. 5)Drag CocoaLumberjack.framework into your Xcode project 6)In your project's settings, under the General tab, add both SVGKit.framework and CocoaLumberjack.framework to the Embedded Binaries section It should now work regardless of whether you build for the simulator or device, and has the added bonus of not making you ship x86 and x86-64 slices in the fat binaries. Plus, this will probably play nicer with bitcode. Doc Block fucked around with this message at 23:41 on Jun 17, 2016 |
|
#
?
Jun 17, 2016 23:25
|
|
|
Doc Block posted:Check the PM I sent you.
|
|
#
?
Jun 17, 2016 23:32
|
|
|
status posted:So I'm finally using Swift (new job yay) and I came across this today: Yes, it's very stupid. Get Refactorator.
|
|
#
?
Jun 17, 2016 23:42
|
|
|
status posted:What the gently caress. I mean the refactor tool can barely refactor Objective-C, but still. Again, I suspect someone is misinterpreting "we can't talk about future products or product plans" as "nothing is planned." Whether or not something is planned is not something anyone from Apple can or should talk about, and even if someone explicitly said "nothing is planned" that shouldn't be taken as a statement from Apple unless they're an extremely senior manager.
|
|
#
?
Jun 18, 2016 00:04
|
|
|
Doc Block posted:While it's obviously a bad idea to try having both macOS and iOS simulator code in the same fat binary, I think it should be entirely possible (and supported) to have both iOS and iOS simulator binaries in the same fat binary. I understand the desire, it's just not currently supported.
|
|
#
?
Jun 18, 2016 00:05
|
|
|
On the other hand Swift has been out for 2 years and refactoring is just not a very hard problem.
|
|
#
?
Jun 18, 2016 00:46
|
|
|
status posted:I mean the refactor tool can barely refactor Objective-C, but still. AppCode handles refactoring really well. It'll even offer to fix your visual format strings for AutoLayout code to match your refactored variable names!
|
|
#
?
Jun 18, 2016 01:04
|
|
|
fleshweasel posted:On the other hand Swift has been out for 2 years and refactoring is just not a very hard problem. 9 times out of 10, doing a find/replace all works just as well for me.
|
|
#
?
Jun 18, 2016 01:48
|
|
|
I like how the arrow to replace all in scope playfully disappears when you actually get near it and has done that since I first got a Mac in 2010.
|
|
#
?
Jun 18, 2016 02:32
|
|
|
eschaton posted:Again, I suspect someone is misinterpreting "we can't talk about future products or product plans" as "nothing is planned." I had the best example of this - at the AppleTV Tech Talks in January I asked several people whether they had plans to add Bluetooth keyboard support, as I work for on remote desktop software where most of our users would want it. Everyone I spoke to (including an input methods evangelist) went beyond simply declining the request or even vaguely saying it's not planned, and told me it wasn't in their vision of the user interaction for the living room experience. Fair enough, it's a reasonable stance to have, except within 2-3 hours of leaving the event a beta was released with that feature. I still can't decide whether this was "not talking about unreleased features" or more a case of the left hand not knowing what the right hand is doing. Or maybe I was just that persuasive..
|
|
#
?
Jun 18, 2016 07:52
|
|
|
After adding a 3rd party framework to my App every time I archive the result shows up in the Other Items list in the archive manager, not in iOS Apps. Searching around I see lots of different solutions to this problem - of course none of them are fixing the issue for me. Is there any way to get any debug or log information to determine why this is happening or am I doomed to search Stack Overflow and randomly try things until I get it working?
|
|
#
?
Jun 23, 2016 16:23
|
|
|
Is the framework actually built for iOS? Is it just a closed source binary, or do you have the source code?
|
|
#
?
Jun 23, 2016 18:35
|
|
|
Doc Block posted:Is the framework actually built for iOS? Is it just a closed source binary, or do you have the source code? Yes. It's the SVGKit framework which I had added as a subproject to mine. Builds and runs fine both in the emulator and on a device. For now I've just pulled their source directly into my project which is building and archiving without issues.
|
|
#
?
Jun 23, 2016 18:42
|
|
|
That project's structure looks...messy.
|
|
#
?
Jun 23, 2016 18:43
|
|
|
|
| # ? Jun 8, 2024 00:36 |
|
|
fankey posted:Yes. It's the SVGKit framework which I had added as a subproject to mine. Builds and runs fine both in the emulator and on a device. For now I've just pulled their source directly into my project which is building and archiving without issues. Assuming you're adding it the way I mentioned earlier, I don't think SVGKit is the problem. I just built and archived a test app that contains SVGKit and it got added to the iOS Apps section of the Organizer window.
|
|
#
?
Jun 23, 2016 21:21
|
|