I recently started creating applications for mobile devices and have successfully completed an application for the iPhone. I am now turning my attention to the Blackberry but haven't been able to find a convincing article or website that states that it can be done or a tutorial on how to do so. Can Blackberry apps be developed on Mac OS X? If yes, how do I go about doing so? Can anyone please point me in the right direction as I only have access to a Mac and really want to get this project on the road. Thanks in advance for your help.
UPDATE:
RIM has released a MacOS Eclipse plug-in for Blackberry Development: http://na.blackberry.com/eng/developers/javaappdev/macosx.jsp
While there is no built-in simulator, the plug-in DOES support USB tethered device debugging for the Torch 9800 handhelds. I plan to get one; they are ~$499 w/no contract. With a Torch and the new plug-in, Blackberry development is possible without using a VM. (Finally!)
PREVIOUS POST:
Building on MacOS works well once you set it up. I've had less luck with the simulator. On the whole though, being able to run Eclipse natively in MacOS and flip to a Windows VM only for debugging is a big win in my book.
You can get a MacOS version of preverify (see link below for details). I do my development with Eclipse on MacOS X and use Ant to build BB apps.
This blog is excellent and has many of the details to get you started:
http://www.azizuysal.com/2009/07/blackberry-development-on-mac-os-x.html (original link is dead. The "wayback machine" provides us with the original text content, but images and styling are lost to the sands of time. Still worth a read.)
The tricky part is getting the simulator to work. There is a Wine-based work-around, but on my computer, while the simulator was able to run under Wine, the LCD output was scrambled.
Currently, I build COD files from Mac, and my Ant build process drops them into a directory that is shared with a WinXP VM. I can run the simulator stand-alone in this VM. Debugging is also possible by installing Eclipse inside WinXP and pointing the debug configuration it at the source directories.
I've actually got a bit more magic. I enabled some of the Java 1.5 features by compiling against 1.5 and then translating the bytecode to 1.3 prior to the preverify script. (Blackberry only speaks a barbaric 1.3 java, flashback to circa 1992). It's not a silver bullet as some features still don't work, but it does cut down on the need to make everything an untyped Object reference.
Lately, I've been working on a x-platform framework to allow me to write app code once and build against both Android and Blackberry (both are Java). The Android part was easy. It's just a bitch to debug anything in Blackberry. Someone working at RIM decided that Blackberry didn't need to keep Exception stack traces unless there was a catch(Throwable), and then they could do something bizarre, non-standard, and undocumented (catching Throwable behaves weird). I've only kinda-sorta figured out a hack to get stack traces using JavaLoader.exe without breaking into the debugger, and it's barely worth it.
p.s., I now do x-platform development with a single code-base targeting Android, Blackberry, and Desktop. Desktop is great for testing app functionality, with very little Blackberry on-device testing needed once features work in the desktop 'simulator' (a Swing GUI built for debugging our games).
Even though certain components of the RIM development platform are java-based, such as the JDE - other components such as the preverifier and device simulators are implemented as native Windows executables.
Basically, the easiest way to do it is to install Windows on your Mac using Bootcamp or Parallels and run inside a real Windows environment on your Mac.
However, there are other "hackier" ways to do it using Wine, MacPorts, and a number of other tools - as an example see this blog post
Related
I have written a JavaFX app running on Windows 10 machine in the office which has problems showing (painting/rendering) certain embedded controls such as a Pane with PdfBox when I connect to it with Remote Desktop for Mac. It shows only a black screen in the app instead of the pdf document.
When I connect using RDP from my Windows 10 machine at home to my Windows 10 machine at work, the app works just fine (the pdf is shown in the app).
I have the same problems using AnyDesk and Teamviewer.
The app only shows PDFs properly using a connection from Windows 10 to Windows 10 with Microsoft RDP.
It might be a JavaFX issue. Similar issues are described here (although not 100% identical):
https://bugs.openjdk.java.net/browse/JDK-8239589
https://bugs.openjdk.java.net/browse/JDK-8229394
However, since I guess Microsoft Remote Desktop for Mac is using the same technology as the Windows Desktop client, I would have expected it to work fine.
I have a Mac Mini M1 running the latest OS (Monterey) at the time of writing this post. I am also using the latest Remote Desktop client for Mac.
This problem is not new and was also present in older releases.
I have tried to play around with screen resolutions, both on Host and Client but nothing good came out of those tests.
Disabled also hardware acceleration in Remote Desktop for Mac preferences but it didn't change anything.
The machine at the office has the following specs (which I cannot change nor update)
Edizione Windows 10 Pro
Versione 20H2
Data installazione: 10/09/2021
Build sistema operativo 19042.1415
Esperienza Windows Feature Experience Pack 120.2212.3920.0
Anyone else who has seen this problem and perhaps resolved it?
Could it be a bug in either PdfBox or Remote Desktop for Mac?
Except for the above issue, the Remote Desktop Client for Mac is working great (not lagging as TeamViewer or AnyDesk) and the user experience is phenomenal.
PS: While this might be considered a programming question (since I wrote the app with JavaFX) but it might be better to post on another forum? If yes, which one? On the other hand, many similar posts (look at the suggested thread on the right) have been upvoted despite not dealing with programming issues.
Thanks.
How do you use PDFBox? I ask because this is not a JavaFX component. If you use a SwingNode for that it might be interesting to try one of my two PDFViewer demos here and see whether the problem persists.
https://github.com/mipastgt/JFXToolsAndDemos#awtimage
The difference is in how I do the rendering and maybe that makes a difference for your use-case too. But of course this is just a wild guess and I can't promise anything.
I'm developing an app in objective-c using Xcode 8. (because old computer)
Currently, my only options for the NSView's appearance are (Default) Aqua, and Aqua.
However, in SDKs starting in 10.14, they've included Mojave's Dark Aqua.
I've added the 10.15 SDK (https://github.com/phracker/MacOSX-SDKs/releases) and added it to XCode (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/) and set the project SDK to it. However, I still don't get the choice to use Dark Aqua.
What should I do? (Alternatively, I could use https://github.com/insidegui/AssetCatalogTinkerer, but when I build it [as it does not include a build with it], I get errors when using the .car it generates.)
With hope,
Conrad
What should I do?
Get yourself a VM app (e.g. VMWare Fusion, Virtual Box, Parallels) and build yourself a Mojave VM then develop & test your app within that.
You will pay a small performance penalty, that's an objective observation of course and YMMV – especially if you're doing heavy graphics – but developing in a VM is quite doable. Indeed when Apple release 10.16 betas, you want to get your software ready, and you don't have a spare machine, then installing it on a VM is far safer than risking it on your primary machine.
HTH
For a new desktop app project I'm researching if it's feasible to create a cross-platform implementation instead of native Windows and OS X apps. Chrome Apps seemed promising, but after browsing through the Chrome APIs there are some things I didn't see that I'll need in my app:
Notifications on changes to files in the local filesystem. (File System Events API on OS X, FileSystemWatcher on Windows.) At first I thought the syncFileSystem API might help with this, but it's apparently only for syncing with Google Drive, which is not what I need. I guess I could workaround this by scanning the directories I'm watching on a timer, but that won't perform well if there are a lot of directories and/or files.
Ability to add context menus in Windows shell and OS X Finder, as I would be able to with a Windows shell extension or OS X Finder plugin.
Ideally (although probably not a hard requirement) get the app into the Windows System Tray / OS X Menu Bar (NSStatusItem).
Can anyone confirm whether it's possible to access this functionality with a Chrome App? If not, can you recommend an alternative cross-platform tool for building an app with these features?
All of the listed features have bugs logged, but no real progress at the moment:
Watch: https://code.google.com/p/chromium/issues/detail?id=148873
File manager integration: https://code.google.com/p/chromium/issues/detail?id=130455
Sys tray: https://code.google.com/p/chromium/issues/detail?id=142450
The first of these to be made available will probably be file manager integration, which is being worked on now.
We'd love to improve watching but it is a significant task to support this on all operating systems and we don't have anyone working on it now.
Sys tray support is something we have no plans to release soon as we're not sure how we want to support this on ChromeOS.
I could not find anything close to the items you have mentioned. I did however find this product: node-webkit that likely would get you onto both your target platforms, use the same basic code-base (HTML5/CSS/JS) and allow some possible per-OS customization. There is even a 'watch' project under NPM that covers your first bullet point. Check node-webkit/wiki for notes on how to add C/C++ extensions to their node build (under using-node-modules.) Project seems active and appears to be backed by Intel (they re-built their XDK product on it to do cross platform.)
I have done a little work on lazarus' free pascal. So when a client asked me to write an application for a mac, after the initial, "it can't be done" stage. (followed by an asp.net maybe stage) i thought about writing it using lazarus.
Question is. I have only a virtual machine running mac OSX, this means that i do not really want to develop on the mac. However, i just cannot seem to get the applications that i have written in lazarus on windows to work on the mac. I have tried the deployment using the Lazarus Wiki and the MACOS folder is empty and so when i put it on the mac it doesn't run the application.
What is the best way of doing this or am i barking up the wrong tree?
It seems you want to do cross-compiling, which is theoretically possible, but may not be practical, for the reasons mentioned by Marco above.
As an alternative, you could install XCode, FreePascal, and Lazarus on a MacOX machine. You could still do your development and some testing on Windows/Linux. When you hit a certain milestone, you can copy your source code to the Mac and compile your application to test and give to the user.
Even if it were possible to easily cross-compile, there some minor differences between platforms, so (especially if it's a GUI app), you would want to test it on an actual MacOS box before giving it to the client.
I've taken the route described by Noah - and I was incredibly surprised that after about three weeks development on Windows, it took about 10 minutes to get the application running on the Mac.
My route was to install Xcode 4.3 on an old Mac Mini running snow leopard, then install Lazarus using the fink version as described here. This took a while but was done in an evening.
Then I just copied my folder across to the Mac, opened the lpi on the Mac, compiled it. It failed so I removed a windows references, recompiled, and it was working. I was truly amazed.
What linker and assembler do you use to generate binaries? To my best knowledge the linker for recent OS X versions is not available in source.
Afaik what you want (crosscompiling to Mac) is not possible for recent versions (and I've done it for PowerPC myself in the past).
The easiest is to use the Unix "file" command on the binary to see what is generated, and make sure it reads something with "MachO" in it. Easiest is if you have a Linux install (where this command is pretty standard), but versions can be found for windows too (cygwin, mingw and 3rd party)
I just upgraded to Flash Builder 4.5, and I am trying to decide whether to install the Win or OS X version, since Adobe only allows you to install on one platform. I have been, up until now, developing an AS3 application using FB 4 under Windows 7 on my MacBook, and my Production Premium CS5 license is also for Windows (and I also do C++/Visual Studio development as well). Now I am going to try the iPhone Packager, to port my app to iOS. It seems to me that the workflow will be awkward once I cross-compile to Objective-C - as I will need to either reboot into OS X to compile and debug, or I will need to run FB 4.5 in a parallels session under OS X (though Adobe's activation freaked out when I tried this with Prod Prem CS4). The FB 4.5 / iOS workflow still requires xCode does it not? Is it foolish to even try this? Should I just bite the bullet and switch over to working in OSX?
Thanks!
I'd say it's better to keep things simple and stick with OSX. Constant switching among platforms is a sure productivity killer. Bite the bullet and stay on OSX - it will pay off on the mid run.
You're better off doing all of this in OSX