I upgrade facebook unity plugin from version 4.2.4 to 4.3.3 yesterday.
For the old version, I just add the jar file in project/plugin/Android and add some specific code to use it.
As for the new version, it just give me a whole facebook android project, what am I supposed to do with it?
Compile it to an jar and use it like before?
Export my project and also with FB project then package it in Eclipse?(which is super waste of time everytime)
In fact I tried both:
1 . this is not works anymore, result in some resource id errors.
2 . I did make out a package, but it can not login like it works before in 4.2.4.
Does anyone meet same problem like I did?
I really think A sdk should not give whole prject out, because as a running project, there is too much sdk to add in, we dont have to much time to deal with each plugin everytime. A big company like facebook should make things easier.
BTW: the instructions on Facebook page is old, I could not get useful information from them.
You should be able to just "Build and Run" with the new 4.3.3 version (if you imported the package and left the structure as is. Be sure to clear out the old Facebook SDK before you import this one.) Unity would automatically compile it in with your project.
To answer your questions on why we did this:
The reason why it got switch away from a jar is that in the older version when it was compiled to the jar, it meant the R class had hard-coded resource ids at compile time (of the jar). Unfortunately, when other plugins were introduced into a project, it reorders the resource ids but doesn't adjust the R class within the jar. This would break integration and make integrating Facebook with the other android plugins useless.
The source of the android files were packaged along with it because several developers requested more ways to edit the code to their needs. There's several android plugins for Unity out there and while we do our best to make sure our Unity SDK plays nice with them, there can be cases were a developer would like extra control on how they merge together.
With that said, since you upgraded your project from 4.2.4 to 4.3.3, did you follow the changelog here: https://developers.facebook.com/unity/change-log-4.x/#131013?
Basically what happened was that since importing a package doesn't let us delete old files, there was no way to clean up projects that used the jar method. Keeping them both in the project breaks the android build. This is only a one time migration that should happen again.
Related
How can I remove the web component part of a Flutter project? I have a project that when it was created was automatically created with web support. Now I am 100% certain the app won't be used for web and I just want to remove support for it. Is there a command in the terminal to help me do that?
I tried checking through the other questions but the others were asking how to disable web support altogether. I just want to remove web support on one project.
In order to fix this, I followed this link. The reason why I can't recreate the project easily is that the project has grown so much that it would be a big hassle to move it into another project. This happened after we updated all of our libraries to their latest versions respectively.
FirestoreWeb caused our project to stop compiling but since we aren't using Flutter web and we don't plan to use it for this project, it wouldn't make sense for us to implement it.
This answer was posted as an edit to the question Remove Web Part from Existing Flutter Project by the OP kobowo under CC BY-SA 4.0.
I'm currently working on a contract job where I've been asked to help integrate a 3rd party SDK with an existing React Native app. The SDK only comes in Android and iOS specific flavors, meaning that it has to be added on the platform-specific side of things (in my case, the iOS side with Xcode).
For the app, the client has created a react native module which gets built into a Library in Xcode, represented by a separate nested Xcode project in Libraries/MyLibrary.xcodeproj from the root of the base Xcode workspace project. This library has several method stubs defined in React Native which will need to be implemented in Swift (and likewise in Android), as this is in these methods that the 3rd party platform-specific SDK is utilized.
The issue I'm having has to do with accessing the 3rd party SDK framework in the library's existing bridging header file. I have followed every tutorial under the sun for how to integrate external frameworks with an existing Xcode project. This includes steps about adding the framework to the project, adding it under the Embedded Binaries and Linked Frameworks and Libraries sections of the project target, adding it under the Build Phases/Link Binary With Libraries section of both the project target and the library target, and adding the framework path under Project Settings/Framework Search Paths. From here, I add the appropriate import statement to my library's Library-Bridging-Header.h file with #import <MyFramework/MyFramework.h> so I can then access the framework in Swift. (This import statement is copied directly from the bridging header file of the sample project included with the SDK, so I know it is correct and should not be given in a different format such as quotes instead of angle brackets).
Regardless of following all of these steps multiple times over and in various combinations, I still get this error at build time: MyFramework/MyFramework.h file not found.
To clarify, MyFramework is just an alias for the actual 3rd party framework I'm attempting to integrate, and MyLibrary is an alias for the existing library with nothing but method stubs given to me by the client to implement in Swift.
Again, I have read every tutorial and forum under the sun, but none seem to address this very specific issue of integrating a 3rd party framework in a xcodeproj Library within the iOS version of a react native app. I would appreciate any new insights or suggestions anyone might have to offer! And please, please don't just post a link to or copy the steps from existing forum posts about a similar-sounding issue, as I've probably already read it 😉. Understand that I think that there is something subtly unique about my specific circumstances which are causing these same steps from the 10+ articles that come up on the first page of Google and StackOverflow NOT to work.
Figured it out! I'll post my solution here in case anybody out there ever runs into the same issue as me.
TLDR - You must add the 3rd party framework in the root of the xcodeproj Library (NOT the top level project) AND ensure that the files were actually copied into that directory, not just referenced from the directory you copied the framework from (be sure to double-check in Finder, since checking the 'Copy if needed' box doesn't always work for some reason). Then, you must add $(PROJECT_DIR) to your xcodeproj Library's Build Settings/Framework Search Paths, and also drag and drop the framework from the root of your xcodeproj Library into the Library's Build Phases/Link Binary With Libraries panel.
I'll address some of the issues with other tutorials/forums that I found, with hopes that it might help someone else that finds themselves as frustrated as I was in this position.
Most only address adding the framework to the base level project, not the obscure case of a project within a project. Therefore, when you start following the steps, it can be confusing to know whether you should be changing the settings of the top-level project or the sub-project. Again, as I discovered, all changes should ONLY be made to the sub-project.
There are a few tutorials that do seem to address this situation regarding a project within a project, but the steps describe adding the framework to the top-level project under Embedded Binaries and Linked Frameworks and Libraries, but I believe the situation described in these tutorials are somehow subtly different than this situation here. Again, only mess with the sub-project.
There's a lot of discussion out there about "umbrella frameworks", but that doesn't really apply to this situation, and again, the terminology similarities can make it seem like it's a similar issue. As I understand it, "umbrella frameworks" are discouraged by Apple, but again, this situation is not the same.
Sorry for the long-winded explanation, but I'm hoping to provide the kind of detail I would have liked to have found when I was searching for solutions for this weirdly obscure problem.
Cheers!
I've been (unsuccessfully) attempting to add the AdMob Adapters to my MoPub integration for the past few days.
Specifically, what has been tripping me up is this quote on various MoPub support pages:
Copy the GooglePlayServicesBanner and GooglePlayServicesInterstitial classes into the com.mopub.mobileads package of your application’s src/ directory.
Now by 'your application' I would assume it to mean my actual project - not the mopub-sdk that it asked me to import.
However, my app doesn't have this com.mopub.mobileads, so I can't copy these files here. It made sense to me that maybe, I should be copying these 2 files into the mopub-sdk project that I imported as this does have com.mopub.mobileads. And I've just come across this page: which states:
The banner and interstitial adapters (e.g. GooglePlayServicesBanner.java and GooglePlayServicesInterstitial.java) should be placed in the com/mopub/mobileads folder in the MoPub SDK.
I realise the above is probably not meant for Elcipse, however....
Does anyone know where these adapters should actually go (when using Eclipse)?
Tried it
If I do copy them into the mopub-sdk project, I get errors because these 2 files reference Google Play Services and the mopub-sdk doesn't have the google-play-services.lib added as a library. My probject obviously does as I'm using it for Leaderboards/Google Ads.
There is no mention (that I can see) anywhere on any MoPub site about these errors and whether I should also add google-play-services-lib as a library to the mopub-sdk project in Eclipse.
What can I do (apart from also adding the google-play-services-lib as a library to the mopub-sdk project in Eclipse), to give Eclipse access to google-play-services.lib? Is there some trick to it?
Here are some screen shots to illustrate what I'm talking about:
^^ Is this the correct place for these files?^^
^^mopub-sdk libraries^^
^^my projects libraries^^
I would create the com.mopub.mobileads package in your app and copy the 2 Java files there.
I'm trying to create my first xlet project.
Can you help me?
I don't know which library I need to download.
What kind of project I have to create? (I'm using netbeans)
This site has a lot of useful info:
http://www.interactivetvweb.org/tutorials/javatv/first_xlet
You can use XletView to view your Xlet.
http://sourceforge.net/projects/xletview/
You will need to get a hold on the various API's, which is somewhat troublesome (I've heard).
But there are also other ways of getting them. For example, if you own PowerDVD, you'll be able to find BDJ.jar somewhere in that package. Add that to your classpath, and you'll be able to compile your Xlet.
If you're running Windows, you can probably develop Xlets with JavaME SDK 3.0 too (sadly not available for Linux though).
Together with my team I'm developing multiple native plugins based on Trigger.io. Since the recent changes I'm not completely sure on the workflow and cannot find anything about it in the documentation either. Some questions that arise:
1) Should one set of inspector projects be used for all the plugins or should each plugin has its own set?
2) Which parts of the inspector projects should be maintained via version control, which should remain local? (fyi: we use SVN)
3) (Android) When using one inspector project for each plugin, whats the best way to import them all as Java projects in Eclipse? Note: each inspector project has 3 sub projects which have the same name across different plugins, so they'd have to renamed? Assuming I have 5 plugins in development, that'd mean that I have to import 15 Java projects into Eclipse. Is this really how it's meant to be?
The most effective way to develop plugins is still something we're working on, how things are right now is probably not as good as it could be (especially for developing multiple plugins), but as things are right now:
1) Each plugin should have its own set of inspector projects.
2) The majority of what the Toolkit puts in the plugins folder is probably best in version control. Things you can safely ignore are the .trigger folder and any bin, gen, or build folders in the inspector projects. If you are trying to keep less files in version control the things you definitely need are the assets/src folder in the ForgeInspector, and any of your own source in ForgeModule, the rest of the inspector project should be regenerated by the Toolkit.
3) I'd recommend using an eclipse workspace per plugin, as the Toolkit regenerates a lot of the code when you update the inspector I don't think it is currently possible to rename the projects.
I thought I'd include a quick overview of what the 3 projects are and why there are 3:
ForgeCore - This is the pre-build core library for Trigger.io apps, its used by both ForgeInspector and ForgeModule so it needs to be a separate project that can be referenced by both
ForgeInspector - This is meant to replicate as closely as possible how your plugin will actually be used, so is basically a stripped down Trigger.io app, its separate to ForgeModule so that you can see what code is in your plugin and what code needs to be put into build_steps.json so it will also be applied to a real Trigger.io app at build time.
ForgeModule - This contains your plugin code