we have two xcframeworks, let say (A) and (B).
we want (A) should be visible and availalbe to public, while (B) we don't want to make available to public. however (B) we are using internally.
i am trying to create xcframework(A) which internally uses xcframework(B). but not able to succeed.
getting error like, no xcframework(A) found.
Related
I am bit confused about the right approach or what are the deciding factors to consider when creating separate hubs vs separate groups within a hub.
In my app there are 2 cases where are are using pub sub:
Multiple user have access to same data. In order to avoid overriding changes done by one user by another we use locking mechanism so that only 1 user can edit the data at my given point. Pub sub notifies users if data they are viewing is locked.
We have some long running report generation process and we use pub sub to get state update of the long running process
We currently have single hub created("MY-APP-HUB") for the entire application, and for both of these use cases have separate groups created "LOCK-DATA-[IDENTIFIER OF THE DATA]-GROUP" and "REPORT-[IDENTIFIER OF THE REPORT]-GROUP". Works well no issues there.
However I am wondering if I should create separate HUB for each action so "LOCK-DATA-HUB" and "REPORT-HUB", and then have separate groups created for each data unit. So for eg within "LOCK-DATA-HUB", create a group "DATA-1-GRP", "DATA-2-GRP", similarly "REPORT-1-GRP", "REPORT-2-GRP" for "REPORT-HUB".
I am honestly not sure if I am doing things correctly. At one hand having all messages associated with an app going through a hub makes sense to me and managing just single token is simpler.
But creating hub per action/feature is not bad either. My only concern here would be if multiple application sharing same pub sub have similar actions going on but that could be avoided by adding some application identifier to the hub name I suppose.
Yes, I'm aware a new bundle ID means a new listing in the store. That's actually what we want - a clean break. It makes sense for our use case. It also gives us the opportunity to correct our bundle ID, which was inconsistent between our products and was using a legacy product name, thereby causing confusion.
I have an existing AppStore Connect app, A. I'm trying to replace it with a completely new implementation of the app, B, that has the same name but a different bundle ID. My intention was to get B completely ready in Connect, de-list A, then publish B. However, Connect is not allowing me to create the app for B:
I'm therefore trying to understand my options. I've looked at simply renaming A first, but that appears to require a new build of A:
I desperately wish to avoid this because because building A is very time-consuming and finicky to get working (legacy tech, nearly no automation). I therefore thought maybe the best approach would be:
Release B with a slightly different name
De-list A when we're ready
Re-publish B with a corrected name
Alternatively, with permission from the business, I could:
De-list A now
Register B using the same name
However, in both cases it is unclear to me whether de-listing an app will make its name become available for registering again. Can anyone confirm or deny this?
Considering Uncle Bob's Clean Architecture (or Onion Architecture)
I have the following scenario:
I want to show the user, information of a place: name, category, coordinate.
I also want on the same screen, a button, that when clicked, redirects to a Map app showing the location of that place.
To redirect to the Map app, there is a simple framework API that receives a coordinate.
For the first problem, I should have a RetrievePlaceInformationInteractor (use case) that would receive a place id and return the name, category and coordinate.
But for the second problem, I don't know if I should:
have a separate OpenPlaceInMapInteractor (use case) that would receive the place id and return the coordinate to be used by that framework API in the Presenter.
have a separate OpenPlaceInMapInteractor (use case) that would receive the place id and use that framework API to redirect to the Map app.
use the same RetrievePlaceInformationInteractor to get the coordinate and fill it in a callback, that calls the framework API, and that would be called when the OpenInMap button was clicked.
The first seems a bit stupid, since it would essentially be an interactor just to retrieve one property, that is already being retrieved by another interactor.
The second forces the OpenPlaceInMapInteractor to access a framework API, which kinda defeats the purpose of the interactor layer not accessing the above layers (sure, I could use a protocol for the API and use dependency injection, but still, I'm relying on a framework specific feature).
The third seems reasonable, but wouldn't I be implementing 2 use cases in one?
What should I do?
Thank you.
Implement a RetrievePlaceInformationInteractor and a OpenPlaceInMapInteractor in the use-cases layers, that both internally call getPlaceDetails from the data access layer, which is where you want to do inversion of dependencies, so that the DB layer depends on the use-cases.
This way you do not repeat yourself, you assign proper names to each of the two use cases. You keep rightfully them separate from one-another, because they are not identical, since they return different parts of the place details.
How do I access the Objective-C class interface defanition that is collected from headers at (pre or actual) compile time so I can provide introspection that is true to the defined public interface.
Problem: F-Script, SuperDB, IKBClassBrowser, CBIntrospection use the class_copyPropertyList() family of functions to introspect objects at run time. While powerful, there are drawbacks…
the runtime has no concept of private and public… everything is
returned
I can not see a reliable way to access the to the ObjC types of
method arguments and returns
Goal: I am researching a iOS app to help teach coding via a live / immediate development environment (similar to SmallTalk, F-Script, SuperDB, IKBClassBrowser, CBIntrospection). I want users to introspect objects, send messages, create new objects, and build and run code via a VM. But I want to limit the functionality to public functions (there is no way Apple would approve the app otherwise) and I want to have access to types so I limit so users can only pass legal objects.
My hope is that there is some way to access Clang or the symbol file to pull this information in way I can use it at runtime. It does not have to be fully automated (I will probably want to limit functionality in some ways)
You're encountering one of the distinguishing characteristics of Objective-C: There is no such thing as private or public API. There's only documented API vs. undocumented API. You can call any method on any object at any time, regardless of whether it appears in a header file. Public/private distinctions exist only for the compiler; at run time, they don't exist, and there's no way to reverse the process and discern what the header files might have said.
I've been using a UIManagedDocument inside of a Singleton class. I create, open and perform with etc and everything was going fine until I needed to have two separate Data stores with an identical Schema. I've made sure everything was done in the same way through the same class (simply storing the second Database in a second static variable and using a BOOL to ensure the correct document gets used.
The problem is that while my original document works fine and the second document gets created fine, I can never seem to get the second document to open when I call 'openWithCompletionHandler' and pass in the block I need it to perform.
So my question is: Are there any special considerations I need to take into account when using multiple UIManagedDocuments in the one project?
Thanks in advance.
Yes there are. The big one is to make sure they both have unique NSPersistentStoreUbiquitousContentNameKey values set in the document's persistentStoreOptions.
See Rich Warren's well documented example:
Syncing Multiple Core Data Documents Using iCloud
And also my GitHub repo that makes multiple documents easier to set up and maintain in some cases:
APManagedDocument