For example I need to import OneDrive SDK.
But I can't use cocoapods due to some reasons.
How to import this library as source files instead? The problem I have is all the import macro are surrounded with <>. For example this doesn't work:
#import <ADALiOS/ADUserInformation.h>
And this works:
#import "ADUserInformation.h"
But if it is possible to import them without of editing the source code?
For your header files, if you want to import with angle brackets, you should pass relative or the absolute path for your header directory to the compiler. Check this answer for more details.
Related
In my dart project projectxyz, I have a dart class declared in in myclass.dart. In main.dart, Android Studio gives two ways, both work, but I did not understand what are the pros and cons of each method:
import 'myclass.dart';
or:
import 'package:projectxyz/myclass.dart';
What is the difference in these two approaches?
That depends on how the main file itself is invoked (and where it's located).
I'll assume the main.dart library is inside the lib/ directory, because otherwise you wouldn't have the two options for importing myclass.dart.
If you invoke the main file with a file: URI, then the relative import of myclass.dart will also be imported with a file: URI. Since Dart uses the import URI to distinguish different libraries, if someone else imports myclass.dart using a package: URI, then it will be treated as two different libraries introducing different classes with the same name.
It used to be that running dart lib/main.dart would treat that as a file: URI. The Dart parser has gotten smarter about that, and now it recognizes that an entry point library in a lib/ directory should have been a package: URI, and replaces the entry point URI with package:projectxyz/main.dart.
After that, it makes no difference whether you use myclass.dart or package:projectxyz/myclass.dart.
Really, there is no difference between the two. Saying import 'myclass.dart' is high-level sugar for import 'package:projectxyz/myclass.dart';.
On the other hand, import 'myclass.dart' is easier to read and understand, and generally looks better. It also decreases confusion as to where exactly your code is being imported from, as anybody who reads this statement knows to look for the file elsewhere in your project. Because of this, you should try to use this form wherever possible.
I am trying to make a custom stepper in Flutter. I copied the implementation of stepper.dart, save my file to my own lib folder and fixed the imports to remove the errors.
import 'package:flutter/src/material/button_theme.dart';
import 'package:flutter/src/material/colors.dart';
import 'package:flutter/src/material/debug.dart';
import 'package:flutter/src/material/flat_button.dart';
import 'package:flutter/src/material/icons.dart';
import 'package:flutter/src/material/ink_well.dart';
import 'package:flutter/src/material/material.dart';
import 'package:flutter/src/material/material_localizations.dart';
import 'package:flutter/src/material/theme.dart';
import 'package:flutter/src/material/typography.dart';
Errors are removed but dart says that "Don't import implementation files from another package."
May I know if it's safe to proceed? OR is there another way to implement custom widgets? Or should I transfer the location of my custom stepper file? Thanks.
Flutter Material Widgets are not meant to be subclassed. Here is what I do to create a customized version of a Widget:
(1) Find the source file of the original widget and copy it to the lib directory of your project.
(you already did that)
(2) remove all import statements from the copied file and insert the line
import 'package:flutter/material.dart'; instead
(3) Check the Dart Analysis for missing packages. To add those click on the unknown (red underlined) class name in the copied source file then hit ALT+Enter and select the context menu entry that offers to add the missing dependency.
(4) Now modify the Widget to your hearts delight.
(5) to use the modified Widget in your project import it like this:
import 'stepper.dart' as my;
(6) You can now access your modified stepper as
my.Stepper stepper = my.Stepper(...);
lib/src from other packages is considered to be private by convention.
The analyzer explains that you shouldn't import such files.
Flutter exports everything it considers public under package:flutter/... anyway. Import these files instead.
See also https://www.dartlang.org/tools/pub/package-layout#implementation-files
I wrote my own macros to output detail message in development environment
#ifdef DEBUG
#define GCLog(fmt, ...) NSLog((fmt), ##__VA_ARGS__);
#else
#define GCLog(...);
I don't want to import this in every file, and I know the shortcoming of PCH file.
So what can I do with this?
You've got four options:
Import some file containing that macro in every file you want to use
it in
Put it in the PCH which is automatically imported for you
Put it in a file and import that file in the PCH
Include that macro in every file you want to use it (generally a bad plan)
Personally when I was writing Objective-C, I would go with option 2 when I wanted something available in every file.
I have objective-c project and I added swift files in it. i created bridge file and imported swift file in some header files without problems.
But I need to import some header files to swift files by adding them in the "<project-name>-Bridging-Header.h" file.
If I put header file in that bridge file and this header file was import swift file before; Xcode give me error message: "file not found" for the swift bridge file.
i.e:
I have project name called: "ProjectBlaBla"
I have header file called "readingPage.h"
I have swift file called: "readingSwift.swift"
swift bridge file's name: "ProjectBlaBla-Swift.h"
I created header bridge file: "ProjectBlaBla-Bridging-Header.h"
I imported "ProjectBlaBla-Swift.h" in "readingPage.h" file without problem and used swift classes inside objective-c
when I import "readingPage.h" in the "ProjectBlaBla-Bridging-Header.h", I got error message in "readingPage.h" said: "ProjectBlaBla-Swift.h file not found"
any suggestions ?
thanks
You are not able to reference -Swift.h files directly or indirectly in -Bridging-Header.h files.
If you open -Swift.h, you will see a line near the top, in my case line 99: #import "/Users/.../...-Bridging-Header.h", meaning -Swift.h already imports -Bridging-Header.h, so importing back creates a circular dependency.
To avoid this, any header you import in -Bridging-Header.h must use forward references to Swift classes or protocols it uses as described in answers to this question.
In short, if readingPage.h uses a Swift class named MySwiftClass you should:
Remove any references to -Swift.h from readingPage.h.
Import -Swift.h in readingPage.m
Insert #class MySwiftClass; into readingPage.h before the class is used, letting Objective-C know that such a class exists and is declared elsewhere.
Check whether the bridging header path is correct. On the left, select your project name -> TARGETS -> Build Settings -> search for Objective-C Bridging Header. Refer the photo below.
Two options
Import the "ProjectBlaBla-Swift.h" inside the "readingPage.m" file instead of "readingPage.h" file
Create a new PCH file named "Prefix.pch" and import "ProjectBlaBla-Swift.h" inside the "Prefix.pch" file.
Note: Prefix.pch is a precompiled header which makes compiling faster. You do not need to reimport any files that are imported in prefix.ch file.
I'm currently trying to add LARSAdController to my iOS project with no success.
As soon as i import the files via #import "LARSAdController.h" in my AppDelegate.h the build process fails and on every occurance of (Class)class in LARSAdController.h i get the cryptic error "Expected identifier". BTW I'm using cocoapods.
Example:
- (void)registerAdClass:(Class)class;
which seems fine to me...
If i create a blank project and import the files they compile, so the problem must be in some relation to my code. Anyone got an idea what may cause this?
Thanks for any help in advance!
class is a reserved word in C++, so I would imagine that some of your project uses Objective-C++.
To solve this, use #import LARSAdController.h in Objective-C implementation files only, and remove its use from header files. You can use #class to forward-declare any occurrences of whatever classes are defined in LARSAdController.h in header files (this is best-practise anyway).
If you need to use LARSAdController from an Objective-C++ class then this is more complicated and you will need to use an Objective-C proxy object or modify their header files (which isn't ideal).