Открытый исходный код C# [закрытое] пространство имен проекта

Вы получаете эту ошибку, потому что в вашем коде вы не инициализировали базу данных огня.

просто добавьте это в свой метод создания действия

FirebaseApp.initializeApp(this);
mAuth = FirebaseAuth.getInstance();
7
задан 3 revs, 2 users 65% 23 May 2017 в 12:30
поделиться

9 ответов

Я пошел бы с чем-то как:

namespace OpenSourceProjectCodeName.MajorFunctionalArea

Например:

namespace VideoWizardMagicThing.Audio
namespace VideoWizardMagicThing.Audio.Codecs
namespace VideoWizardMagicThing.Video
namespace VideoWizardMagicThing.Video.Codecs

Вы не должны идти абсолютно обезумевшие от пространств имен и всего, в чем Вы, возможно, нуждаетесь, один или два MajorFunctionalArea. Однако не зная, как проект структурирован или что он, трудно сказать.

6
ответ дан 7 December 2019 в 12:25
поделиться

Если бы это - открытый исходный код и будут участники, я выбрал бы MyTool.

0
ответ дан 7 December 2019 в 12:25
поделиться

Если бы можно позволить себе изменить его позже, я пошел бы с MyName. MyTool. Если Вы - единственный человек, пишущий инструмент, Вам нужен полный кредит, и наличие Вашего имени в пространстве имен не причиняет никому боль.

При принятии новых участников можно удалить имя из пространства имен, но только если другие люди на самом деле сделали большой вклад. Если бы большинство работы является Вашим, я оставил бы его внутри.

0
ответ дан 7 December 2019 в 12:25
поделиться

Вы могли сделать MyToolProject. MyTool. Или, Вы могли просто придумать некоторое творческое название своей "организации" и просто иметь это как, каковы все Ваши будущие проекты с открытым исходным кодом будут, даже если это будет всего один прямо сейчас. Затем у Вас мог быть MyCreativeOrgName. MyTool.

0
ответ дан 7 December 2019 в 12:25
поделиться

MyTool имеет проблему, которая имена не уникальны; Вы - достижение конфликтов имен. MyCompany.MyTool не применяется в Вашем случае, если Вы не хотите давать себе некоторую маркировку.

Мне на самом деле скорее нравится конвенция Java инвертирования URI, связанного с продуктом. Для компаний это - веб-сайт компании. Для Вас – у Вас есть блог / персональная домашняя страница, адрес которой, вероятно, скоро не изменится? Затем используйте имя с TLD и инвертированным доменом второго уровня. В моем случае: net.madrat.MyTool.

Я знаю несколько человек, которые используют TheirName.MyTool который прекрасен. Howver, это становится проблемой, как только существует второй участник.

0
ответ дан 7 December 2019 в 12:25
поделиться

Я предложил бы получить MyOrganization и использовать его. Если Вы когда-либо берете деньги для работы, Вы испытываете необходимость в объекте, и это могло защитить Вас от ответственности. Довольно легко настроить что-то.

Или просто используйте название MyOrganization и создайте объект позже, но Вы рискуете конфликтами официального имени, и т.д. если Вы не настраиваете его сначала.

0
ответ дан 7 December 2019 в 12:25
поделиться

MyTool в значительной степени походит на код проекта / торговая марка?

В этом случае, если Вы хотите категоризировать его далее, не используя Ваше название организации или имя, зацепить промышленность или проблемную область, это предназначено для обращения.

VideoEditing. MyTool

Учет. MyTool

HomeAutomation. MyTool

0
ответ дан 7 December 2019 в 12:25
поделиться

Я закончил с Idunno.* для нескольких проектов (мой веб-сайт), и SharpSTS.* для основного (поскольку это - название проекта),

-1
ответ дан 7 December 2019 в 12:25
поделиться

MyOrganization. Технология является все еще рекомендуемым способом запустить пространство имен с.

Я раньше имел подобную проблему пространства имен мое хобби проекты прежде. Таким образом, я только что составил название группы разработки одной (Вы хотите иметь короткий и читаемый), и начал использовать его.

Однако имейте в виду, что удобство использования является все еще ключом. Например, вот, одно исключение из правила. Наши Lokad с открытым исходным кодом Общие Библиотеки следуют за пространством имен самой.NET (т.е.: Система или Система. Поточная обработка). Поэтому существуют многочисленные повседневные помощники и расширения, которые должны быть доступны нашим разработчикам без того, чтобы даже замечать, что они усиливают код non-BCL.

Это также заставляет объявления использования выглядеть более хорошими.

0
ответ дан 7 December 2019 в 12:25
поделиться